1 ELECTRONIC BILL PRESENTMENT SYSTEM WITH CLIENT SPECIFIC 

2 FORMATTING OF DATA 

; 3 

. 4 BACKGROUND OF THE INVENTION 

- 5 The present invention relates to a financial transaction system and method, and 

- 6 more particularly, to a network-based system and method for billing and payment. 

- 7 Recently, there has been an increase in the popularity of performing financial 
, 8 transactions using the Internet as a centralized network for linking the individual 

9 financial systems of a plurality of entities transacting business with one another. With 

0 10 the recent explosion in e-commerce, the increasing acceptance of the Internet as a 

11 less expensive and more efficient way of doing business, and the advent of new server 



12 technology and sophisticated online security systems, Internet-based financial 

13 transactions are becoming ever nriore common. Advantageously, an Internet-based 

14 financial transaction system for bill presentment and payment may reduce many of the 

15 transaction costs associated with other financial transaction systems, such as 
fli 16 preparation costs, banking fees, and costs for clearing, reconciling and closing, 
i^l 17 Moreover, such a transaction system may seamlessly handle transactions from 
p 18 virtually any entity with Internet access, regardless of the nature of the business, 

19 geographic location, size, or trading currency, even those entities for which the costs 

20 of traditional invoicing, presentment and payment have traditionally been high. 

21 Traditionally, invoice presentment and bill payment procedures have required a 

22 capital outlay for the equipment to prepare and distribute each invoice, as well as 

23 collect and reconcile payment of the invoice. Additionally, there are costs and 

24 collection delays associated with the multiple steps required between multiple parties 

25 to effect invoice presentment and bill payment. Such steps may include the payee's 

26 preparation and distribution of invoices by mail (which may take up to a week to reach 

27 payers) or electronically; one or more invoice approvals by individuals or departments 

28 within the payer's organization (e.g. a purchasing manager); invoice adjustment or 

29 dispute by other individuals or departments; payment authorizations by other 

30 individuals or departments; payment issuance, either electronically or by issuance of a 

31 paper instrument, such as a check, (again, typically by mail); receipt of payment at the 



1 payee's side, either by the payee, the payee's bank, a lockbox, or other payment 

2 receipt entity; and processing of the paynnent either at the payee's bank, at the 

3 payee's accounts receivable, or both. This entire process nnay take several weeks, 
. 4 and requires separate accounting records to be kept and harmonized at both the 

- 5 payer's (accounts payable) and payee's (accounts receivable) sides, and/or within 

- 6 other decentralized record keeping systems. 

- 7 There are further costs and collection delays associated with any adjustments 
, 8 to the invoice that may be made by either the payer or the payee. When an 

9 adjustment is made within one record keeping system, the adjustment must be 

10 communicated to the other system(s) so that a corresponding adjustment can be 

Jjll made. For example, an invoice adjustment made by the payer results in the payer's 

Ol2 entry of an adjusted invoice amount into its accounts payable, as well as the payer's 

\ol3 mailing a copy of a manually-adjusted invoice to the payee, so that the payee can 

'%4 update its accounts receivable. 

"m SUMMARY OF THE INVENTION 

^7 A first aspect of the present invention is to provide an electronic bill 

;|8 presentment and payment system. The system comprises a billing database for 

L49 storing billing data related to a plurality of bills. Each bill represents an amount 

20 payable to a billing client from a paying client. An application server receives a 

21 plurality of instruction files, each representing a transaction for reading and 

22 manipulating billing data, performs the transaction utilizing data included in the 

23 instruction file, and provides a data response file complying with a predetermined 

24 format. A presentation server is coupled to the application server and includes a 

25 document database comprising a plurality of document style sheets. Each style sheet 

26 represents a format for the response data in a predetermined document format 

27 corresponding to one of the clients. The presentation server receives the response file 

28 and generates a client document utilizing data extracted from the response file and the 

29 document style sheet corresponding to the client. More specifically, the style sheet 

30 utilized by the presentation server may be a style sheet associated with the billing 

3 1 client associated with the transaction. 
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1 The document style sheet may include a plurality of document fields and the 

2 presentation server may populate each document field by matching data from the data 

3 response file to populate the document field. More specifically, the data response file 
. 4 may comprise a plurality of data fields and a plurality of predetermined tags, each tag 

5 identifying one of the plurality of data fields and the presentation server may utilize a 

■ 6 tag to identify data for inclusion in the client document. Further, one of the 

- 7 predetermined tags may identify a data field which identifies the billing client 

8 associated with the transaction and the presentation server may utilizes the data field 

9 which identifies the billing client to select a document format for presenting the 
10 response data to the client. 

1 The data response file comprises an XML message and the client document may be 

*12 an HTML document. 

W 

~^fll3 In another aspect of the present invention, the presentation server may further 

^4 receive transaction request files from each of the biller clients and payor clients and 

Nl5 generate the instruction file in response thereto. The transaction request files from 

c|6 each of the biller clients and the payor clients may be HTTP posts and the instruction 

Jji? file may be an XML message. 

Ms Yet another aspect of the present invention is to provide a method of providing 

|.|9 electronic bill presentment and payment services to a plurality of billing clients and a 

20 plurality of paying clients. The method comprises receiving an invoice file from each of 

21 the plurality of billing clients and populating a billing database with data from each 

22 invoice file. The invoice file representing amounts payable to the billing client from at 

23 least one paying client. The method further comprises receiving an instruction file 

24 from a client representing a transaction for reading or manipulating data in the billing 

25 database, performing the transaction utilizing data included in the instruction file, 

26 generating response data, and providing a client response document comprising the 

27 response data in a specified document format corresponding to the client. 

28 The specified document format may be defined by a style sheet which includes 

29 a plurality of document fields and the step of providing the client response document 

30 may comprise populating each document field by matching data from the response 

31 data to a document field. More specifically, the response data may comprise a 
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1 plurality of data fields and a plurality of predetermined tags, each tag identifying one of 

2 the plurality of data fields and the step of populating each document field comprises 
^ 3 matching the field to a tag identify data for inclusion within the document field. 

^ ^ 4 Further, one of the predetermined tags may identify a data field which identifies 

5 the billing client associated with the transaction and the step of providing a client 

6 response document may comprise identifying the billing client and selecting a 

' 7 document format associated with the billing client for providing the client response. 
* 8 The response data may be formatted an XML message and the client response 

9 document is an HTML document. 

^ 1 BRIEF DESCRIPTION OF THE DRAWINGS 

.yi2 Figure 1 is a block diagram of an electronic bill presentment and payment 

7j3 system consistent with the present invention; 

4|4 Figure 2 is a flowchart illustrating exemplary operation of a web server in 

s 15 accordance with one embodiment of the invention; 

^6 Figure 3 is a flowchart illustrating exemplary operation of an application sen/er 

fM7 in accordance with one embodiment of the invention; 

08 Figure 4 is a flowchart illustrating exemplary invoice loading in accordance with 

n9 one embodiment of the invention; 

20 Figure 5 is a workflow diagram illustrating exemplary host user operations in 

21 one embodiment of the invention; 

22 Figure 6 is a workflow diagram illustrating exemplary biller system operations in 

23 one embodiment of the invention; 

24 Figure 7 is a workflow diagram illustrating exemplary biller system 

25 administration operations in one embodiment of the invention; 

26 Figure 8 is a workflow diagram illustrating exemplary payer system operations 

27 in one embodiment of the invention; 

28 Figure 9 is a workflow diagram illustrating exemplary payer system 

29 invoice/payment operations in one embodiment of the invention; 

30 Figure 10 is a workflow diagram illustrating exemplary payer system reporting 

31 operations in one embodiment of the invention; and 
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1 Figure 1 1 is a workflow diagram illustrating exemplary payer system 

2 administration operations In one embodiment of the invention. 

3 

. 4 DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 

5 Exemplary Bill Presentment and Payment System 

~ 6 Figure 1 illustrates an electronic bill presentment and payment system 10 



" 7 consistent with the present invention. System 10 includes at least one biller system 

. 8 12, at least one payer system 14, at least one business sen/ice provider system 16, 

9 and a payment processing system ("ASP") 18, in communication with one another via 

10 a network 20. The network 20 may be a TCP/IP compliant network, such as the 

Jd 1 Internet. It should be appreciated that each of the biller system 12, payer system 14, 

|jl2 business service provider system 16 and ASP 18 (also referred to herein as 

©13 "workstations") may be remotely located from each other and may be controlled by 

jl4 separate entities. Alternatively, permutations of each of the biller system 12, payer 

35 system 14, business service provider system 16 and ASP 18 may be commonly 

QI6 controlled and/or located at a single entity. 

SjI7 The biller system 12 and payer system 14 may interface with the ASP 18 in real 

38 time via a web browser or other TCP/IP compliant software. The biller system 12 and 

ih49 payer system 14 may comprise computing devices with appropriate network interface 

20 hardware and software for establishing a TCP/IP session with a web server 30 at the 

21 ASP 18 and for executing an application for interfacing with the web server 30. The 

22 application may be typical HTML Internet web browser software, such as Netscape 

23 Navigator™ or Microsoft Internet Explorer™, which is capable of receiving HTML 

24 documents from the web server 30 and returning HTTP posts to the web server 30. It 

25 should be appreciated that such HTML interface enables an operator of a biller system 

26 12 or payor system 14 to read, write, manipulate data, and otherwise interact with the 

27 ASP In real time. 

28 The biller system 12 and payor system 14 may also interface with the ASP 18 

29 utilizing a batch interface for exchanging large quantities of data in data files of a 

30 predetermined format. The batch interface may use TCP/IP or other network type 
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1 sockets or may utilize a dedicated network circuit such as a value added network 

2 (VAN). 

^ 3 The business service provider system 1 6 may be an exchange or other service 

- 4 bureau application providing a plurality of business processing services to its clients 

5 (which may include the biller system 12 and/or payer system 14). One such business 

6 processing service may be electronic bill presentment and payment, as may be 

7 provided using a system and/or method consistent with the invention. In such a 

8 configuration, from the point of view of the service provider system 16, the ASP 18 

9 may be a back end system for performing such bill presentment and payment portions 
10 of the overall services. The service provider system 16 may communicate with the 

yi 1 ASP 1 8 utilizing data files with a predefined format to assure that the content of such 

jSll data files may be recognized by the intended hardware and/or software. The 

213 predetermined data file may be a data file with each data element including a label or 

'^44 tag to identify the data. 

"^15 A typical language for structuring such tagged field data files is known as the 

6 extensible markup language (XML) and the predetermined data structure is known as 

^7 a schema. The data is referred to as an XML message. Utilizing the Internet 20, the 

H8 service provider system 16 and the ASP 18 may establish a TCP/IP session and 

l19 exchange XML messages. 

20 It should be appreciated that, in an alternative embodiment, a biller system 12 

21 or a payer system 14 may operate an accounting system interface application rather 

22 than a web browser. In this case, the biller system 12 or payer system 14 will 

23 communicate with the ASP 18 utilizing XML messages, and the XML communication 

24 may be similar to that which may occur between the ASP 18 and the service provider 

25 system 16. Such an accounting system interface application may enable the biller 

26 system 12 or payer system 14 to avoid manually reading data from an HTML 

27 document and manually re-entering into an accounting system. More specifically, the 

28 XML messages may be used to directly input content into the accounting system or, at 

29 a minimum, automatically populate content onto an accounting system data entry 

30 screen. 
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1 The ASP 1 8 may comprise one or more web servers 30 coupled to a secured 

2 zone network 22 between two routers 24, 26 serving as firewalls, one for protecting 
~ 3 the internal private network 28 of the ASP 18 and one for blocking unauthorized 

- 4 Internet access. This zone 22 is often referred to idiomatically as a DMZ (i.e. "de- 

5 militarized zone"). It is noted that one or more firewalls may be placed between any 

6 one of a number of components of the present invention for security purposes. In this 

7 standard firewall configuration of a DMZ 22, the web servers 30 may be coupled to the 

8 Internet 20 by a first router 24 and coupled to a private network 28 by a second router 

9 26, On the "front end", the web servers 30 may establish the TCP/IP sessions and 
_10 communicate with the biller systems 12, payer systems 14, and business service 

fll 1 provider systems 16, as described above. On the back end, the web servers 30 may 

-yl2 use XML messages to make remote processing calls (RPCs) to an application server 

^is 32 (described hereinbelow in further detail) and may receive XML response messages 

4S14 to such calls. An invoice loader 34 (described hereinbelow in further detail) may be 

.„ 15 provided for transmitting batch input to a database server 36, which may store invoice 

|i 6 and other financial, transactional, or non-financial data. Those skilled in the art will 

1117 recognize that such data may be generated by one of any number of billing systems, 

r|8 e.g., SAP, Oracle Financials, JD Edwards, People Soft, Great Plains, etc. The data 

*^i9 outputted by these billing systems and input into the system may come in a variety of 

20 formats including raw data, print file format, and X-12 ANSI 810 (EDI). The database 

21 server 36 may include a database application 35 (described hereinbelow in further 

22 detail) for reading and writing to the raw data stored on the magnetic media of the 

23 database. 

24 Web Server 

25 With reference to the flowchart of Figure 2 in conjunction with Figure 1 , an 

26 exemplary fundamental operation of a web server 30 in accordance with one 

27 embodiment of this invention is shown. A TCP/IP session may be established at step 

28 40 with a remote client, which includes appropriate exchanges of passwords and/or 

29 other authentication messages to verify that the remote client has authorized access. 

30 Clients may be either workstations which interface with the server 30 using a browser 

31 interface, or, alternatively, software clients which interface with the server 30 using 

7 



1 XML messages. Step 42 represents a determination as to whether the remote client is 

2 operating a web browser or whether the client is operating an XML enabled 

- 3 application. If the remote client is operating a web browser, the server 30 may send 

- 4 out an initial HTML document to the client at step 48. This initial document may be the 

5 main menu page that the operator at the remote client might expect to see 

6 immediately after logging onto the system utilizing the browser. The server may then 

7 receive an HTTP post from the remote client at step 50 and, in response to such HTTP 

8 post, build an XML message for making a remote processing call to the application 

9 server 32 at step 52. More specifically, the XML message is based on the content of 
10 the post and a predetermined schema for the function that the operator of the remote 

^"^1 1 client has requested via the HTTP post. For example, if the operator had selected to 

. ;fl2 view a list of open invoices from the HTML menu document, the server might build an 

33 XML message for requesting open invoices from the application server 32 based on 

%4 the schema for viewing a list of open invoices in response to the HTTP post. 
Ms step 54 represents the server making an XML remote processing call to the 

fi6 application server 32 utilizing the XML message. An XML response message may be 

^;i7 received back from the application sen/er 32 at step 56. The web server may then 

^^48 utilize the content of the XML response message to build an HTML document to send 

[l9 to the remote client in response to the remote client's HTTP post at step 58. More 

20 specifically, each web server 30 may include a style sheet database 52 that stores 

21 style sheets for various documents that may be sent to remote clients and may provide 

22 different style sheets for the same document based on different clients. As such, the 

23 branding, look and feel, and layout of documents may be varied on a client-by-client 

24 basis. The step of building an HTML document may therefore also include selecting a 

25 style sheet corresponding to the remote client and combining the style sheet with the 

26 content of the XML response message to build the HTML document. The style sheet 

27 may include data fields and building the HTML document may include populating the 

28 style sheet by matching data elements from the response message with fields on the 

29 style sheet. The HTML document may then be sent to the remote client at step 59, 

30 and, returning to step 50, another HTTP post may be received and the foregoing steps 

3 1 repeated for that HTTP post. 

8 



1 Because it is envisioned that tiie operator of the biller system 12 (Figure 1) may 

2 provide electronic bill presentment and payment services to several of it suppliers, 

3 each operating a payor system 14, it is envisioned that style sheets will be common to 

4 ail biller systems 12 and payor systems 16 when interfacing with the ASP 18 with 

5 respect to reading, writing, and manipulating data at the ASP 18 related to amounts 

" 6 due to the biller operating the biller system 12. In which case, a style sheet is selected 

- 7 by identifying the biller system 12 utilizing an element of the response message and 

8 selecting a style sheet corresponding to such biller system 12. 

9 Similarly, it is envisioned that he operator of a payor system 13 may provide 

10 electronic bill and payment services to several of its customers, each operating a biller 
system 12. It is envisioned that style sheets will be common to all biller systems 12 

jC12 and payor systems 16 when interfacing with the ASP 18 with respect to reading, 

"Jl3 writing, and manipulating data at the ASP 18 related to amounts due to the biller 

"^4- operating the biller system 12 from such operator of the payor system 13 providign the 

M5 services to its customers. In which case, a style sheet is selected by identifying the 

H6 payor system 14 utilizing an element of the response message and selecting a style 

^7 sheet corresponding to such payor system 14. 

-18 Alternatively, if at step 42 the remote client is determined to be a client utilizing 

r|9 an XML enabled application instead of a web browser, the web server may send an 

20 initial XML message to the remote client at step 60. The web server may then receive 

21 an XML message from the remote client at step 62 and validate the XML message at 

22 step 64. If necessary, the content may be transformed into an XML message 

23 compliant with the schema needed for making a remote processing call to the 

24 application server at step 67 if it did not validate at step 64. 

25 The schema-compliant XML message may then be used to make the remote 

26 processing call to the application server at step 66. At step 68, a response XML 

27 message may be received from the application server, and, at step 70, the response 

28 XML message may be returned to the remote client. Thereafter, returning to step 62, 

29 another XML message may be received and the foregoing steps may be repeated. 

30 It should be appreciated that the above description represents an exemplary 

31 process utilized for interacting with each remote client. In operation, the server may 
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1 be operating with a plurality of remote clients simultaneously and/or utilizing a multi- 

2 tasking based operating environment. Furthermore, a plurality of web servers 30, 

- 3 each communicating with a plurality of different clients, may each be capable of 

- 4 making XML calls to the application server 32 to perform the above described 

5 functions. 

6 Application Server 

7 The application server 32 may perform the main processing of the business 

- 8 functions carried out by the ASP 1 8. The application server 32 may operate within a 

9 hardware and software environment. The software environment may comprise a 

plO plurality of applications that may be object-oriented and/or table-driven, whereby new 

Jl 1 products, applications, modules and/or transaction types may easily be integrated. 

-W12 Such software components may include, e.g., an operating environment 41 (e.g. 

il3 Microsoft Windows NT™, Windows 2000™, or Sun Solaris™), transaction processing 

_^J14 software (e.g. Microsoft Transaction Server™), communications software, database 

1^ 15 tools (e.g. RogueWave™), query and/or reporting software (e.g. Seagate's Crystal 

ffll6 Reports™), a database interface 33, a message parser/builder 51 , a business function 

1^17 selection object 38, one or more business objects 37, and/or one or more other 

gl8 applications, which may be table-driven. As described hereinbelow with respect to 

19 Figure 3, the message parser/builder 51 may verify access levels of clients accessing 

20 the web servers 30, as well as verify the format of XML messages and build 

21 appropriate messages to pass to the appropriate selection objects 37 for execution. 

22 The transaction processing software may be a component-based transaction 

23 processing application for developing, deploying, and managing high performance, 

24 scalable, and robust enterprise, Internet, and intranet server applications, which 

25 defines an application programming model for developing distributed, component- 

26 based applications and provides a run-time infrastructure for deploying and managing 

27 these applications. A clustering application may optionally be provided for load 

28 balancing and fail-over services to cluster distributed application servers into a single, 

29 high-performance, highly available environment of application server resources, 

30 thereby avoiding bandwidth, latency, and congestion problems and providing multi- 

3 1 server scalability for unlimited concurrent user access. The query and/or reporting 

10 



1 software may be an application or object providing for an environment in which client 

2 reports and file download formats are easily customizable. One or more business 
- 3 objects 37 or applications may reside on the application server 32, such business 

4 objects 37 or applications being the components that perform the central transactional 

5 functions of the server 32. The business objects may receive XML messages in a 

6 predefined format and return XML response messages in a predefined format. Menus 

7 of options (as shown in Figures 5-1 land described hereinbelow) may be made 

8 available to the client by the message parser/builder 51 (or, as those skilled in the art 

9 will recognize, by one of any number of components of the invention, e.g., selector or 
10 another business object). 

531 1 As discussed hereinbelow, exemplary business objects may include an object 

.f:^2 for reviewing invoices, an object for making adjustments to invoices, and an object for 

"tfll3 initiating invoice payment. One or more of any of the foregoing described 

Jl4 applications may access the database server 36 via the database interface 33 and/or 

15 database application 35 for purposes of retrieving and modifying its data. Other 

Cl6 applications may be provided, consistent with the provision of billing, payment, or other 

S[i7 financial or non-financial services. For example, an e-mail notice application may be 
provided for sending e-mail notices of the invoices to one or more payer systems 14 

149 which are set up to receive e-mail notices. While the foregoing components of the 

20 application server 32 may be referred to herein as "applications", "modules", 

21 "components", "interfaces", and/or "objects", it should be understood by those skilled in 

22 the art that such labels should not be construed in any way to be limitations. Any of 

23 the components of the application server 32 may comprise machine-readable 

24 programming code embodied in a tangible medium, e.g., Java beans. Depending on 

25 whether the embodiment of the invention is object-oriented, such components may or 

26 may not be formal objects. A table at the end of this Detailed Description lists 

27 exemplary objects and corresponding XML messages in one embodiment of the 

28 invention. It is noted that the business objects of the present invention should be 

29 modular, i.e., functionality may be added to, deleted from, or modified in the system by 

30 adding or removing business objects. Thus, each business object should be 

31 constructed with expected input and output data only, as though it were a "black box". 
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1 The internal processes of each business object "black box" are not relevant to the 

2 overall operation or nnaintenance of the system, to the extent that any business object 

3 with a given set of expected input and output data may be substituted for an existing 
_ 4 business object for performing a similar or identical function having the same set of 

5 expected input and output data, wherein the system need not ever require knowledge 

^ 6 of the internal operation of the business object for proper functioning or maintenance. 
- 7 With reference to the flowchart of Figure 3, which illustrates an exemplary 

8 operation of the application server 32 in one embodiment of the invention, in 

9 conjunction with Figure 1 , the general operation of the application server 32 will now 
10 be described. First, an XML remote processing call may be received at step 72 from 

oil one of the web servers 30. The message parser/builder 51 may receive from the web 

jjiz servers 30 either an XML message from the software client or an HTTP post from the 

^:!l3 workstation client. If an XML message is received from a software client, the message 

fll4 parser/builder 51 may verify that the particular client has appropriate access levels for 

4|15 sending such XML message, thereby preventing a person from manually writing an 

iJ6 XML message for an option that is outside of the permitted workflow for the client. 

fll7 After verifying access levels, the message parser/builder 51 may verify that the XML 

sj8 message is the exact format needed for passing to the selection object 37. If not, data 

^9 may be extracted and the appropriate message is built. The message may then be 

20 passed to the selection object 37, which may pass the message to the appropriate 

21 business object 37 for execution. In the case of an HTTP post from a workstation, the 

22 message parser/builder 51 may build an XML message for performing the transaction 

23 based on the post and the access levels. The message may then be passed to the 

24 selection object 37, which may pass the message to the appropriate business object 

25 37 for execution. 

26 A business function selection object 38 may then make a call at step 74 to the 

27 appropriate business object 37 associated with the XML call. The selected business 

28 function object may execute and generate at step 76 XML calls to the database 

29 interface 33. The database interface 33, in turn, may utilize predefined instructions at 

30 step 78 for directing the database server 36 to access and/or write data into the 

31 database tables. In one embodiment, the predefined instructions may be a group of 

12 



1 instructions, e.g., SQL calls. It is noted, however, that the business function objects 37 

2 may not directly perform the SQL calls at step 78. The database interface 33 object 
- 3 may exist so that the relational structure of the database 36 may be modified without 

. - 4 modifying each of the business function objects 37. Each database relational structure 

5 may merely need to be defined in a database structure file (not shown) that may be 

6 used by the database interface 33 object to structure the appropriate SQL calls for 

7 execution at step 78. A response to the SQL call may then be received at step 80 

^ 8 from the database 36. A single XML call at step 76 from a business function object 37 

9 may cause the database interface 33 object to initiate several SQL calls at step 78. 

Q 10 Therefore, if more than one SQL call is necessary (as determined at step 90), a 

Jj 1 1 plurality of such calls may be initiated at step 78, as necessary, and the corresponding 

IaI 12 responses may be received at step 80. Once the database Interface 33 object has 

|jl3 completed the SQL calls at step 78, it may build (at step 82) and return (at step 83) a 

j! 14 response XML message to the business function object 37. The response XML 

1^ 15 message may then be received at step 84 by the business function object 37. A 

I5I6 business function object 37 may need to initiate several XML calls to the database 

;^17 interface 33 object during performance of the selected business function, at step 76. 

018 Therefore, if more than one XML call is necessary (as determined at step 85), a 

19 plurality of such calls may be initiated at step 76, as necessary, and the corresponding 

20 database calls may be generated (at step 78) and may be received (at step 80), and 

21 appropriate XML responses may be built (at step 82), returned (at step 83), and 

22 received (at step 84). Once the XML calls to the database interface have been 

23 completed at step 76, (i.e. the business function has been completed), the business 

24 function object 37 may build a response XML message at step 86 and may return the 

25 XML response message to the web server 30 at step 88, and the foregoing steps 

26 repeated for a subsequent XML remote processing call which may be received at step 

27 72. 

28 Invoice Loader 

29 With reference to the flowchart of Figure 4, which illustrates an exemplary 

30 invoice loading operation in one embodiment of the invention, in conjunction with 

31 Figure 1 , the general invoice loader 34 operation will now be described. The invoice 
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1 loader 34 module may provide batch input to the database 36. This may be useful 

2 because many enterprise accounting systems may export an invoice file on a periodic 
. 3 basis. The batch invoice file may then be sent at step 100 to the invoice loader 

. 4 module 34 via one of any number of means 53, e.g., as an e-mail attachment, FTP 

5 load, an EDI VAN (value added network), or another private network link. Therefore, 

~ 6 the invoice loader module 34 may include a network interface (not shown) for coupling 

- 7 to the Internet and may include one or more private network interfaces (not shown) for 

8 coupling to EDI VAN'S or other private network interfaces. Each of these network 

9 interfaces may be a network card, or may comprise such other hardware and software 
10 as may be appropriate to effect the network interconnection. Alternatively, the invoice 

Ol 1 loader module 34 may couple only to a local area network 28 at the processing facility 

M2 (i.e. at the geographic location of the ASP 18), and one or more routers 24, 26 in the 

5513 DMZ 22 may serve to couple the invoice loader 34 to the Internet 20 and to each 

^4 private network, as may be appropriate. 

\|15 Once the invoice loader module 34 receives the invoice file at step 102, it may 

}46 verify that the file is in the appropriate invoice loader format at step 104. Typically, the 

547 biller may be responsible for running the necessary translation program to convert the 

HI 

sis invoice file from the biller's accounting system to the invoice loader format However, 

29 it may be possible for the file to arrive at the invoice loader module in the accounting 

20 system format, in which case the invoice loader module may then identify the 

21 accounting system format and run an appropriate translation program at step 106 to 

22 convert to invoice loader format. Exemplary formats from which invoices may be 

23 loaded include ANSI X12 810, flat ASCII files, or well formed XML schemas. 

24 Once the invoice file is in the invoice loader format, the invoice loader module 

25 34 may enter the invoices into the database 36 at step 108 and may, if appropriate, 

26 send out e-mail notices at step 1 14 to one or more payer system 14 users indicating 

27 that an invoice is available. To this end, the invoice loader module 34 may therefore 

28 include an invoice loader application 39. The invoice loader application 39 may make 

29 appropriate calls to a database application 35 for loading the invoices. More 

30 specifically, the database application 35, which may run on the database server 36 (or, 

31 alternatively, on the application server 32), may provide for the raw data stored on the 
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1 magnetic media to be logically accessible in a relational database table format. 

2 Predefined instructions for accessing and writing data into the tables may be sent to 

3 the database application 35. In one embodiment, the predefined instructions may be a 

4 group of instructions, e.g., SQL calls. The invoice loader application 39 may therefore 

5 execute appropriate SQL calls for writing the invoice data to the database 36. 

6 Once the invoice data is in the database 36, e-mail notices of the invoices may 
' 7 be sent out to one or more payer system 14 users who are set up to receive e-mail 

8 notices at step 114, An e-mail notice application 31 may be provided on the 

9 application server 32 for making appropriate SQL calls to the database 36. Such calls 
10 may be made for purposes of detecting new invoices at step 1 1 0, as well as 

% 1 1 determining, based on the identity of the payer, if an e-mail notice is required, at step 

]^ 12 112. More specifically, the e-mail notice application 31 may search the database 36 

13 for a flag or other identifier of a new invoice, and then, for each new invoice, may 

2 14 obtain data from a payer's profile indicating whether an e-mail notice is appropriate, 

'H5 and if appropriate, the address to which the e-mail notice should be sent. The e-mail 

016 notice application 31 may then send the e-mail. Alternatively, the e-mail notice 

lyl? application 31 may mn on the invoice loader module 39 instead of running on the 

38 application server 32. 

Pl9 Database Server 

20 The database server 36 may be an OLTP (on-line transaction processing) 

21 system, embodied in a server, such as Microsoft SQL Server 7™, Oracle 8™, Sybase 

22 Adaptive Server R12™, DB2™, Informix™, or another ODBC-compliant database. 

23 The database server 36 may be configurable for sharing with other applications, 

24 including access by a report writer application, and may comprise a distribution and 

25 replication protocol (DRP) device. A backup database server (not shown) may also be 

26 provided, wherein some or all of the data on the database server may be mirrored to 

27 the backup database server. In this configuration, in the event an application 

28 performing a transaction on the database server experiences failure, the application 

29 may start at the backup server location and proceed from the point of failure, thereby 

30 preserving transaction integrity. 
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1 The database 36 may be a relational database, i.e., data management 

2 technology modeled such that all data is organized as though it is formatted into 

3 tables, with the table columns representing the table's fields or domains and the table 

4 rows representing the values of the table's fields or domains. Data between tables 

5 may be related to one another, using, for example, pointer data. Data may be logically 

6 organized as tables but not necessarily physically stored as such. The database 

' 7 interface 33 may access and update data via a language interface or "structured query 

8 language" (SQL) calls. The database 36 may comprise a relational database where 

9 the payer and biller profiles (which may include access control data and/or dispute 

10 rules) may be related between payer systems 14 and biller systems 12. The message 

1 1 parser/builder 51 may retrieve access control data from the database 36 when a 
Ml2 workstation client logs on. Similarly, business service provider profiles may be stored 
Sl3 in the database 36 and may include access control data for one or more business 
1214 service providers 16. 

^115 Invoice data stored on the database 36 may include invoice-specific data 

ol6 received from the biller 12 each time the biller 12 sends an invoice to the ASP 18. 

2tl7 Such data may include, e.g., the identity of the biller and payer, invoice line items, and 

^11 8 settlement and payment options. Biller profile data may be stored on the database 36 

jpl9 and may include items that a biller 12 need only enter once, and may change only 

20 periodically thereafter. Such items may include dispute rules and access levels for 

21 each biller workstation with system access. The dispute rules may be payer-specific 

22 or may be may applied globally to all payers. 



23 Payer profile data may be stored on the database 36 and may include items 

24 that a payer 14 need only enter once, and may change only periodically thereafter. 

25 Such items may include access levels for each payer logon ID (referred to as a payer 

26 workstation) with system access. 

27 Client Types 

28 In one embodiment, two client types may access the ASP 18, a workstation 

29 client (e.g. a browser) interfacing with the system 18 utilizing HTML documents and 

30 HTTP posts, and a software client interfacing with the system 1 8 utilizing XML 

31 messages. Both billers and payers may comprise workstation clients, and the 
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1 message parser/builder 51 may present different work flow options to each via menus. 

2 Host (or "administrator") users and help desk users may be biller or payer workstations 

3 having access levels which are a subset of all access options available to the biller or 

4 payer. Host users (who may be affiliated with a business service provider system) 

5 may control most non-invoice related data and functionality. A biller system user may 

6 control invoice related data and functionality associated with a specific billing 

7 company. A payer system user may have specific functionality associated with all 

8 related invoice transactions to the paying company. Help desk users may be provided 

9 access to the system in order to troubleshoot users' questions, 

10 Host users (also referred to herein as "administrators") may configure and 

11 maintain the system. A single SuperUser account may be established for each 

12 installation of the system. The SuperUser may be pre-configured with the system and 

13 have all permissions allowed. The SuperUser may create additional host users with a 

14 subset of their permissions. Host users may act as system administrator, whose role is 

15 to manage users in the system, handle database administration, monitor system 

16 activity, manage enrollment and handle system error conditions. 



17 A host user may create a biller system and one or more biller administrator 

18 users associated with such biller system. This action may bind the specific biller 

19 system user to the invoices associated with the biller. Additional biller system users 

20 may be created by the biller administrator. 

21 Similarly, A host user may create a payer system and one or more payer 

22 administrator users associated with such payer system. 

23 A help desk user may be a hybrid type of user. The help desk user may 



24 manage technical support issues. This user may log in as any biller or payer system 

25 user and use the system as if they were actually that user. The application may 

26 disallow any changes made by this user from being committed to the database. The 

27 help desk user may be created by a host administrator or SuperUser, A user created 

28 as a help desk user may only perform the help desk functionality, with all other system 

29 functionality being disabled. 

30 A help desk user may log on to the system through the standard logon page 

31 with their own user ID and password. The help desk user may then be immediately 
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1 presented with the standard logon page, where he or she will then log on with the user 

2 ID of the person he or she is helping and the help desk user's password. Upon a 

3 successful log on, the help desk user may be connected as if he or she were the 

4 actual user, without the ability to modify any data. 

5 Login and Access 

6 The application server 32 may authenticate each client via a logon process, and 

7 each client may have a specific set of access levels for performing certain functions, 

- 8 which may be a subset of all of the functions available to the particular biller, payer or 
9 business provider. The message parser/builder 51 may maintain a table of access 

,.-40 levels for each client which is currently logged into the system. With respect to 

31 1 transaction requests, when an HTTP post is received from a workstation or an XML 

idl2 message is received from an application client, the message parser/builder 51 may 

513 only build the XML message from the HTTP (or pass the XML message received) if 

f?14 the client has appropriate access levels. With respect to responding to a transaction 

- 15 request, the message parser/builder 51 may control the clients' work flow and limit the 
'fA6 menu choices which appear in the outbound XML message to those that would be 

f 4? available as next steps in the work flow for the particular client. 

£18 The system may permit a user (i.e. the operator of a biller, payer or business 

' 19 service provider workstation) to gain access by clicking on a "login" button on the initial 

20 screen, or by going directly to the logon URL without having to navigate through the 

21 initial pages by simply entering the full URL in the browser, "bookmarking" the page, or 

22 using a "favoritesMype feature of the browser. The system may present the user with 

23 a logon page, wherein he or she must specify a valid user ID and password to gain 

24 access. If an invalid ID or password is entered, the user may be told that an Invalid 

25 ID/password was entered. In one embodiment, if a user enters a valid user ID and an 

26 invalid password five times in a row, the system may "disable" the user ID (i.e. the 

27 system 18 will not present the workstation defined by the ID with other system options 

28 until another workstation, with appropriate access levels, performs a function to reset 

29 the "disabled" account). If, after this period, the user enters a valid ID and password, 

30 the system may display a message indicating that their account has been disabled. 
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1 Alternative authentication methods may include any method of verifying the 

2 identity of a user or a component of the invention and may include a security 

3 mechanism such as one or more of a digital signature, a PIN number, a password, a 

4 smart card, or a "master" or "challenge" key. In one embodiment of the invention, an 

5 XML script may create a Java applet that monitors the active application and interacts 

6 with a separate security server residing within the application server. The Java applet 

7 may be configurable to interrupt the current application to prompt for authentication, 

8 such as by a digital signature, a PIN number, a password, or a master key, and to 

9 communicate with the security server to effect the authentication. If the security 

10 operation is successful, the application may continue without interruption; otherwise, 

11 the application may be terminated according to the XML script. Alternatively, the 

12 foregoing process or a part thereof may be used for transferring data between any two 

13 components in an embodiment of the present invention, including those external to the 

14 invention, such as an end user, a client, a financial institution, a back office, an 

15 administrator, an e-mail or fax recipient, or a server. One or more of the foregoing 

16 security operations may be implemented using application security middleware, such 

17 as Ubizen's MuitiSecure™ ETS, MultiSecure™ ASE, or MultiSecure™ WAC. Further 

18 security means may comprise one or more of the following: password or PIN number 

19 protection, use of a semiconductor, magnetic or other physical key device, biometric 

20 methods (including fingerprint, nailbed, palm, iris, or retina scanning, handwriting 

21 analysis, handprint recognition, voice recognition, or facial imaging), or other log-on 

22 security measures known in the art. Password protection may include certain validity 

23 requirements upon establishing a password, e.g., disallowing more than two 

24 consecutive characters in a password, disallowing the same password for a minimum 

25 of six consecutive password changes, and/or disallowing more than one user-initiated 

26 password change per day. Passwords may be set to expire after a certain number of 

27 days, and an inactive user account may be set to expire or become disabled after a 

28 certain number of days of nonuse. 

29 Following logon, as described above, a user may be presented with 

30 predetermined work flow options based on the access levels available for his or her 

3 1 particular workstation. 
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1 Security 

2 Point-to-point data communications over the Internet may be handled by secure 

3 sockets between the web server 30 and client 12, 14, 16. Exemplary protocols used 

4 may include Netscape's Secure Socket Layer (SSL) or secure HTTP. As those skilled 

5 in the art will recognize, other embodiments of the invention may include one of any 

6 number of methods for two-way data encryption and/or digital certification for data 

- 7 being input to and output from the web server 30, to provide security to data during 

8 transfer. In particular, an algorithm such as Triple DES may be used to encrypt such 

9 data as account numbers, credit card numbers, tax ID numbers and/or passwords. 
10 Host User Workflow 

fgl 1 Figure 5 illustrates an exemplary host user workflow in one embodiment of the 

system. When a user logs in 501 to the system using the user ID of a host user, the 

&3 system may display a host administration or "welcome" page 502. The system may 

Jl4 display the user*s name at the top in the form of a "Welcome 'Username'" message, for 

15 personalization. The system may display a host administration page containing host 

Q6 statistics and a list of "action items" with current counts and links to the corresponding 

fl|7 pages. Such counts may include biller count, payer count, enrollment request count, 

is connected user count, invoice load error count, total invoice count, and paid invoice 

H9 count. The system may calculate these reported statistics at the time the active user 

20 logs on to the system and/or may update these statistics in real time. As part of 

21 reporting these statistics, a query tool may be integrated into the system to generate 

22 pre-formatted reports. The system may permit the host user to return to this page by 

23 clicking on a link that may be present on every page during system access. One area 

24 of the screen may contain navigation buttons grouped into categories, e.g., 

25 administration 503 and reports 504. The system may permit these categories to be 

26 expanded into subcategories that modify another portion of the screen. One area of 

27 the navigation frame may contain the user name (not the user ID) who is logged on. 

28 The system may permit clicking on this link to modify the user's basic profile 

29 information, which the system may store as global information on the database. 

30 The system may permit a host user to select an option to edit payers 507, 

31 wherein the system may permit the administrator to add, modify, or delete payers from 
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1 an edit payer page 508. A payer may be a company that does business with one or 

2 more billers in the system. Each payer system may have one or more users that will 

3 have certain permissions. The edit payer page 508 may contain a list of current payers 

4 in the payers list box. When an administrator selects a payer, the system may display 

5 information for that payer in the company information section. The system may permit 

6 an administrator to add information for a new payer in the company information section 

7 and select "add" to add the new payer. The system may permit company data to be 

8 entered for the following exemplary fields, which the system may store as global 

9 information on the database: name, "division", address, city, state, zip, country, SIC 

10 code, TIN, and organization type. The system may require the company name plus 

1 1 "division" to be unique. The system may permit modify and delete operations to be 

12 performed on the currently selected payer. The system may require fields for 

13 company information, such as name and phone. The system may display the list of 

14 payers and permit search and find operations, next and previous page navigation, first 

15 letter selector navigation, and scrolling navigation, in order to effectively display large 

16 numbers of payers. 

17 The system may provide a user list box, which may be populated with the 

18 selected payer system's user names. As the administrator clicks on each user in the 

19 list, the system may display the user's information in the user information section. The 

20 system may provide an "edit users" option for directing the administrator to an "edit 

21 users" page, if the payer has been saved to the database. The system may provide 

22 an "edit users" page to allow the administrator to add, modify, or delete users 

23 associated with the current payer. This page may display the name of the payer at the 

24 top. The system may permit the host user to select an option to edit the active user 

25 profile 505, wherein the system may direct the host user to a page 506 displaying the 

26 organization name of the host, biller or payer at the top, to establish the context of the 

27 current edit. The system may permit information to be maintained and edited at this 

28 page, which the system may store as global information on the database, Including, 

29 e.g., last name, first, middle, phone, fax, e-mail, e-mail2, user id, password, 

30 confirmation, language, currency and privilege group. The system may require certain 

31 fields for user information, such as last name, first name, e-mail and phone. The 
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1 system may provide a reset password button to reset the selected user's password to 

2 the default setting (e.g. user's last name). The system may also permit the 

3 administrator to add a new user to the current payer by entering information into the 

4 user information section and selecting "add". The system may require the combination 

5 of last name, middle initial and first name to be unique. The system may permit modify 

6 and delete operations to be performed on the currently selected user. The system 

7 may provide a checkbox for temporarily deactivating a user The system may 

8 automatically send an e-mail to a new user after they have been added, informing 

9 them of how to connect and logon to the system. The system may not permit a host 
^0 user to set permissions. The system may permit a host user to create biller or payer 

system administrator users, both of whom may be afforded all permissions, 
ifc The system may permit the host user to select an option to edit billers 509, 

#3 wherein the system may permit the administrator to add, modify, or delete billers from 

34 an edit biller page 510, A biller may be a company that does business with one or 

ns more payers in the system. Each biller system may have one or more users that will 

^6 have certain permissions. The edit biller page 510 may contain a list of current billers 

l|7 in the biller list box. When an administrator selects a biller, the system may display the 

pis information for that biller in the company information section. The system may permit 

19 the administrator to add information for a new biller in the company information section 

20 and select "add" to add the new biller. The system may permit company data to be 

21 entered for the following exemplary fields, which the system may store as global 

22 information on the database: name, address, city, state, zip, country, SIC code, TIN, 

23 and default template type. The system may require that the company name be 

24 unique. The system may permit modify and delete operations to be performed on the 

25 currently selected biller. The system may require certain fields for company 

26 information, such as name and phone. 

27 The system may permit a host user to select an option to edit biller websites 

28 and logos, directing the user to a biller website and logo page 51 1 . The system may 

29 display a list of billers, and upon selection of a biller from the list, the system may 

30 populate the company information area with details about the current biller. For each 

31 biller, the system may permit a list of company logos and websites to be edited. The 
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1 system may make new logos available to the system with an "add" button which 

2 uploads the logo file, and may likewise permit logos to be removed from the system 

3 with a "remove" button. The system may display a list of websites via a listbox 

4 containing the sites and a site details edit area. Upon selection of a website in the list, 

5 the system may populate the site details section. The system may permit the URL, 

6 description, and type of website to be edited. The system may provide a delete button 

7 for removing a site from the list. The system may provide a save button to save the 

8 current website. The system may provide a new site button for emptying the edit area 

9 to allow a new site to be entered and saved. The system may provide selectable links 

10 for accessing the biller's enrollment page and biller profile page. The system may be 

1 1 adapted to store logo and website data as global information on the database. 

12 As described above with respect to users associated with payers, the system 

13 may provide a user list box, which the system may populate with the selected biller 

14 system's user names, and the system may provide an "edit users" option for directing 

15 the user to an "edit users" page, where the system may allow the administrator to add, 

16 modify, or delete users associated with the current biller. 

17 The system may permit the administrator to add a new user to the current biller 

18 by entering information into the user information section. The system may require that 

19 the combination of last name, middle initial and first name be unique. The system may 

20 permit modify and delete operations to be performed on the currently selected user. 

21 The system may provide a checkbox for temporarily deactivating a user. The system 

22 may be adapted to store contact information as global information on the database, 

23 including, e.g., last name, first, middle, phone, fax, e-mail, e-mail2, user ID, password, 

24 confirmation, language, currency and privilege group. The system may require certain 

25 fields for user information, including last name, first name, e-mail and phone. The 

26 system may provide a reset password button for resetting the selected user's 

27 password to the default setting. The system may be adapted to automatically send an 

28 e-mail to a new user after they have been added, telling the user that they have 24 

29 hours to log in and change their password or the account will be disabled (e.g. where 

30 the password is set to the default of user's last name; accounts may be re-enabled by 

31 a host user). The e-mail may inform them of how to connect and logon to the system. 
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1 The system may permit a host user to select a "relationships" option 512 for 

2 being redirected to a relationships page 513 for viewing, modifying and/or establishing 

3 biller/payer relationships. This page may contain a list of current billers in the billers 

4 list box and two payer list boxes: available payer and related payer. When a user 

5 selects a biller from the list box, the system may update the two payer list boxes. The 

6 available payer list box may contain all payers not currently related to the selected 

7 biller that have been approved by the biller. The related payer list box may contain all 

8 payers currently related to the selected biller. The system may provide "add" and 

9 "remove" buttons to allow payers to be added or removed from the related payers list 
AO The system may display in a Payer 1D# field the system-wide biller-customer number 
"Ml for the selected payer from either list. The system may not save this page unless all 
y2 related payers have Payer lD#'s and may display a warning message may inform the 
^3 user of this condition. The system may be adapted to store payer/biller relationship 
Ii4 data as global information on the database. 

J 5 The system may permit the host user to select an option to add/modify/delete 

y 6 administrators associated with the host. The system may permit the administrator to 

mi add a new user to the channel host by entering information into a user information 

fls section and selecting "add". The system may require that the combination of last 

H9 name, middle initial and first name be unique. The system may permit modify and 

20 delete operations to be performed on the currently selected user. The system may 

21 provide a checkbox for temporarily deactivating a user. The system may be adapted 

22 to store contact information as global information on the database, including, e.g., last 

23 name, first, middle, phone, fax, e-mail, e-mail2, user ID, password, confirmation, 

24 language and privilege group. The system may require certain fields for user 

25 information, such as last name, first name, e-mail and phone. The system may provide 

26 a reset password button for resetting the selected user's password to the default 

27 setting. The system may be adapted to automatically send an e-mail to a new user 

28 after they have been added, informing them of how to connect and logon to the 

29 system. 

30 The system may permit a host user to select an option 514 to change security 

31 information, in which case the system may permit administrator, biller and payer 
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1 security settings to be modified at one or more user security/privilege pages 515. In 

2 the various privilege pages, the system may permit the privilege group to be entered 

3 and presented in the local language. The system may present the list of functional 

4 access permissions in the language of the active user. 

5 For changing privilege information relating to host administrators, the system may 

6 permit administrator privilege groups to be defined and edited. The system may 

7 display a list of available permissions, the permissions being inherited from the active 

8 user currently logged on. The system may provide a listbox containing all defined 

9 administrator privilege groups, wherein selecting a previously defined group may 

10 cause the system to populate the list with the corresponding settings. The system 

1 1 may provide an "all" button for setting all permissions when selected, and a "none" 

12 button for clearing all permissions when selected. The system may permit add, modify 

13 and delete operations to be performed on the current privilege group. The following 

14 list may be representative of exemplary permissions that may be set for host 

15 administrators; create new billing entities; create/maintain new biller system 

16 administrators; activate new biller system administrators; create new paying entities; 

17 create/maintain new payer system administrators; activate new payer system 

18 administrators; create/maintain new host administrators; maintain biller-payer 

19 relationships; reset biller/payer system administrator user passwords; maintain 

20 adjustment codes; edit mailing lists; and run canned reports. 

21 For changing privilege information relating to billers, the system may permit 

22 biller permissions to be defined and edited. The system may display a list of available 

23 permissions, the permissions being inherited from the active user currently logged on. 

24 The system may provide a listbox containing all defined biller privilege groups, wherein 

25 selecting a previously defined group may cause the system to populate the list with the 

26 corresponding settings. The system may provide an "all" button for setting all 

27 permissions when selected, and a "none" button for clearing all permissions when 

28 selected. The system may permit add, modify and delete operations to be performed 

29 on the current privilege group. The following list may be representative of exemplary 

30 permissions that may be set: create/maintain new biller system users; activate biller 

31 system users; create/maintain new biller system administrator users; reset user 
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1 passwords; maintain adjustment codes; edit biller bank liolidays; edit biller/payer 

2 agreements; edit mailing lists; and run canned reports. 

3 For changing privilege information relating to payer system users, the system 

4 may permit payer permissions to be defined and edited. A list of available permissions 

5 may be displayed, the permissions being inherited from the active user currently 

6 logged on. The system may display a listbox containing all defined payer privilege 
' 7 groups, wherein selecting a previously defined group may cause the system to 

- 8 populate the list with the corresponding settings. The system may provide an "all" 

9 button for setting all permissions when selected, and a "none" button for clearing all 

10 permissions when selected. The system may permit add, modify and delete 

Jfl 1 operations to be performed on the current privilege group. The following list may be 

/J312 representative of exemplary permissions that may be set: create/maintain new payer 

513 system users; activate new payer system users; create/maintain new payer system 

;g4 administrators; reset user passwords; maintain adjustment codes; edit payer bank 

'45 holidays; edit biller/payer agreements; edit mailing lists; and run canned reports. The 

jpl6 system may be adapted to store any of the foregoing permission data as global 

'ri? information on the database. 

2fi8 The system may permit a host user to select a "load invoices" option 51 6 for 

Jjl9 being redirected to a page 51 7 for performing a manual load of selected invoice files or 

20 controlling the automatic loading times of biller uploads. The load invoice page 51 7 

21 may contain a list of current billers in a billers list box. When an administrator selects a 

22 biller, the system may use files found in the directory or subdirectories used for invoice 

23 loading associated with the selected biller to populate the invoice files list box. The 

24 system may permit the host user to select one or more files from the invoice files list 

25 box and select an option for loading them at that time, which may force the system to 

26 load the selected invoice files immediately. After the process is complete, the system 

27 may display any error information that occurred during processing may on this page. 

28 The system may handle the automatic loading of invoices through a scheduling 

29 interface. 

30 The system may permit a host user to select a "host profile" option 505, which 

31 may direct the user to a host profile page 506 for allowing the host's profile information 
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1 and payment method information to be edited. The system may allow data to be 

2 entered for the following exemplary fields, which the system may be adapted to store 

3 as global information on the database: name, address, city, state, zip, country, phone, 

4 number, fax number, and maximum invoice amount allowed. The system may use the 

5 maximum invoice amount allowed field to establish a threshold for a maximum 

6 payment for a single invoice. The system may permit invoice values that exceed this 

7 amount to be loaded into the system but not to be paid through the system. The 

8 system may also permit payment method information to be modified at this page, i.e. 

9 the system may permit the administrator to define the payment methods that the host 

10 has currently enabled. The system may display a payment methods area consisting of 

11 two listboxes, an available methods box containing all the payment methods that are 

12 currently unassigned by the host, and an enabled methods box containing all the 

13 methods the host has enabled. The system may provide two buttons to allow methods 

14 to be transferred from box to box. The system may provide save and cancel buttons 

15 at the payment methods area. Exemplary available payment methods may include 

16 ACH debit, credit card/procurement card, and paper check. 

17 The system may permit the host user to select a reports option 504, which may 

18 cause the system to display subcategories that correspond to the available reports. 

19 Exemplary reports the system may generate may include: access report 521 ; invoice 

20 load and error reports 522; invoice payment reports 523; bottomline payment reports 

21 524; analyze RDBMS (Relational Database Management System) 525; review 

22 performance statistics 526; and activity report 527. Activity report 527 may cause the 

23 system to detail the following exemplary activities: create new biller/payer; create new 

24 contacts; add/remove biller-payer relationships; edit biller bank holidays; edit 

25 biller/payer profiles; reset biller/payer system administrator passwords; add/edit 

26 adjustment codes; edit mailing lists; edit contact info; create new logins for contacts; 

27 edit login info; disable/enable logins; and help desk login. The system may permit the 

28 user to select from among various reporting options and/or filters 528 (which the 

29 system may be adapted to store as global information on the database), and the 

30 system may then generate a report and permit the user to view and/or print it at a 

31 report page 529. 
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1 other functionality which the system may provide for the host user includes a 

2 password change selection 530, which may cause the system to direct the user to a 

3 password change routine 531 ; a help selection 533, which may cause the system to 

4 direct the user to a help routine 534; and a logout routine 550. 
5 

6 Biller System Workflow 

■ 7 Figure 6 illustrates an exemplary biller system workflow in one embodiment of 

8 the system. When a user logs in 601 to the system using the user ID of a biller, the 

9 system may display a biller system administration or "welcome" page 602. The system 
qIG may display the user's name at the top in the form of a "Welcome 'Username'" 

'-^1 1 message, for personalization. The system may display at a biller system 

iril2 administration page key biller statistics and a list of "action items" with current counts, 

yglS amounts in local currency and links to the corresponding pages, as well as information 

JJ14 about the basic functionality of the main topics. The system may also display at this 

^15 page information provided by the administrative user regarding how to contact the 

J516 administrative user. The current counts may include total invoices, closed invoices, 

J;"|17 paid invoices, unpaid invoices, and adjusted invoices. The system may provide a 

018 selection to the user for filtering and/or sorting the counts. The system may permit the 

" 19 biller system user to return to this page by clicking on a link that may be present on 

20 every page during system access. One area of the screen may contain navigation 

21 buttons grouped into categories, e.g., administration 603 (discussed further 

22 hereinbelow at "Biller System Administration"), invoices/payments 680, and reports 

23 604. The system may expand these categories into subcategories that modify another 

24 portion of the screen. One area of the navigation frame may contain the user name 

25 (not the user ID) who is logged on. The system may allow the user to click on this link 

26 to modify his or her basic profile information. The system may provide other 

27 functionality, including a "help" button 650 for directing the user to a help section 651 

28 and a "logout" button 652 for logging the current user out of the system. 

29 The system may allow the biller system user to select an option to edit the 

30 active user profile, wherein the system may direct the biller system user to a page 

31 displaying the organization name of the biller at the top, to establish the context of the 
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1 current edit. The system may permit information to be maintained and edited at this 

2 page and may store the information as global information on the database, e.g., last 

3 name, first, middle, phone, fax, e-mail, e-mail2, password and confirmation. The 

4 system may require certain fields for user information, including last name, first name, 

5 e-mail and phone. The system may include this information in e-mails which may be 

6 sent through the system and may also make this information available to biller and 

7 payer system administrators. 

8 The system may permit a biller system user to select an option 605 to display 

9 invoices based on selected criteria and/or specify general search criteria for listing 

10 invoices. Depending on the selection, the system may direct the user to a "view 

1 1 options" page 606 for filtering and sorting. The system may provide a view options 

12 page 606 to allow the user control over the subset of data that will be displayed and 

13 the order in which the data will be presented. To further facilitate the presentation of 

14 invoices, the system may permit settings associated with a specific report to be 

15 automatically saved and used again the next time the user generates the report. 

16 Considering the time it may take to generate certain reports (e.g. lengthy reports), the 

17 system may also provide an option to bring this page up before running a report, to 

18 limit the scope and time. The view options page may consist of three exemplary 

19 areas: filter, sort and options, in the filter area, the system may provide the following 

20 exemplary choices: by date (past due, eligible for discount, due within xxx days); and 

21 by status (paid invoices, adjusted invoices, unpaid invoices, paid through another 

22 source); and by payer (all payer, specific payer); and by attribute range between xxx 

23 and yyy (none, invoice numbers, store / location, purchase orders, purchase request 

24 number, invoice issue dates, dollar amount, bill of lading numbers, receiving location 

25 zipcodes, invoice aging). The system may also provide the ability to search for invoice 

26 number, store or location number, routing number and P.O. number, by using 

27 wildcards. The system may provide a sort area to allow returned results to be sorted 

28 in ascending or descending order according to the following exemplary criteria: due 

29 date, invoice number, invoice date, purchase order number, net amount due, store or 

30 location number, and invoice aging. In one embodiment, the system may allow sorting 

31 criteria and order to be determined by a sort order combo box, which may default to 
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ascending, and three sort criteria boxes, the first of which defaults to due date, while 
the rest default to no sort criteria (spaces). The system may provide an options area 
with the following exemplary choices: display all in one page or show count (with the 
default being all in one page), remember and use previous settings, and show view 
options page before presentation. The system may be adapted to store filter, sort, and 
options data as global information on the database. 

The system may allow a biller system user to select an option to display a page 
607 for listing invoices matching specified criteria. The system may display at this 
screen the filter/sort criteria that are in use for this display. The system may display 
invoices using a paging concept (i.e. 1 - 20 of 362). When displaying invoices, the 
system may remove any existing navigation area, so as to optimize the invoice display 
area. In one embodiment, the system may display a page separated into two sections, 
with the header section containing non-scrolling data and/or buttons and the body 
section that scrolls as necessary, depending upon the width of the browser window 
and the number of invoices being displayed. The header section may contain the 
following elements: 

• The user's selection criteria. I.e., All Invoices - Past due. 

• The display range text in the format of first - last of maximum, i.e., 1-20 of 200. 

• "Next 'n'" may cause the system to navigate the user to the next "n" invoices, i.e., 
"Next 20". If the last "n" invoices are currently being displayed the system may 
disable the "Next" button. 

• "Previous 'n'" may cause the system to navigate the user to the previous "n" 
invoices, i.e., "Previous 20". If the first "n" invoices are currently being displayed the 
system may disable the "Previous" button. 

• "All" may cause the system to change the mode from displaying a page of invoices 
to displaying all invoices, and the system may label the button "Page", i.e., 1-200 of 
200. If the "Page" button is selected, the system may display at this page the first 
"n" invoices, and system may label the button "All". 

• "Back" may cause the system to return to the previous screen, step, or function. 

• "Search" may cause the system to perform a search in the current invoice list by 
using the "Find" feature. The system may permit only the invoices currently being 
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1 displayed to be searched. The system may allow the user to type a string to search 

2 for before selecting the "Search" button. The system may search each invoice may 

3 for the specified string. If a match is found, the system may scroll the invoice 

4 record into view and select the text found. Selecting "Search" again may cause the 

5 system to find the next instance of the string. The system may permit wildcard 

6 searches. 

7 • "Show Selected" may cause the system to display all invoices that have been 

8 manually checked. In the last column of the invoice list, the system may allow a 

9 user to select individual invoices. While the user remains on this page, the system 

10 may maintain in a list all invoices that are marked as selected. If the user switches 

1 1 the context of this view, the system may not remove any selection made by the 

12 user. Clicking on the "Show Selected" button may cause the system to display all 

13 the invoices the user has selected. The system may change this button to either 

14 "Page" or "All", depending on the state of the selection when this button was 

15 pressed. Selecting this button again may cause the system to return the invoice list 

16 to its previous mode. The system may display all selected Invoices, even if they 

17 exceed the page limit. 

18 • "Close" 608 may cause the system to mark as closed all invoices that are selected. 

19 The system may display to the user a confirmation message before the invoices 

20 are closed, e.g., "You have selected 24 invoices to close. Are you sure you want to 

21 close these invoices?" The system may not permit closed invoices to appear in any 

22 active queries. The system may subject invoices that are marked as closed to host 

23 archiving and purging criteria. 

24 • "Paid Through Another Source" may be provided by the system as an option for the 

25 biller system user to mark an invoice as closed by selecting desired invoices and 

26 clicking on the "Paid through another source" button. Once this occurs, the system 

27 may, for the invoices in question, update their audit trail to reflect that they were 

28 paid outside the system, and then change their status to "Closed". 

29 In the body section, the system may display all invoices in table format. The width of 

30 the table columns may be proportional to the width of the browser window. If the 

31 browser window is narrowed, the system may decrease column widths appropriately 
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1 and wrap text within eacli column, as necessary. If an invoice has adjustments, the 

2 system may highlight that line in color to indicate this fact. The system may link the 

3 invoice number field to the invoice detail page. The system may link the status field to 

4 the invoice history page, at which the system may display a full status history for the 

5 selected invoice. By default, the system may display the following exemplary columns: 

6 payer name, invoice number, due date, status, net amount due, amount to pay, P.O. 

7 number, P.O. requisition number, store number, and select. 

8 The system may permit the biller system user to select an option to display the 

9 details of a selected invoice, which may cause the system to direct the user to an 

10 invoice detail section 610. The system may use one or more predetermined, 

11 customizable and/or selectable template schema (which may be stored as global 

12 information on the database) to format the biller detail, and the system may provide a 

13 single biller multiple templates from which to select The invoice detail page may 

14 contain various sections. One section may display summary information for the 

15 selected invoice, information about the biller, information about the particular invoice, 

16 and/or information about the payer. The system may provide selectable buttons for 

17 obtaining more information about the current invoice, e.g., items 611, messages 612, 

18 e-mail 613, status 614, shipping info 615, discounts 616, and notes 617. The system 

19 may display line items that have been adjusted in a different color. Upon selection by 

20 a user of the items button 611 , the system may toggle the header view from showing a 

21 detailed header description to allowing the user to perform basic search operations on 

22 the details of this invoice. The items button 61 1 may cause the system to toggle to 

23 header. Clicking on the header button may cause the system to return to the previous 

24 view, thereby providing more space for viewing details on the current page, as follows. 

25 Another section may contain the line items that make up the invoice. The system may 

26 color code highlight line items that have been adjusted. Each line may have a clickable 

27 line number. Clicking a line item's number may cause the system to expand the line to 

28 show its detail. Clicking a particular adjustment may cause the system to display a 

29 window with details about that specific adjustment. Another section may contain the 

30 invoice summary. For both the original amount billed and the amount to pay, the 

31 system may calculate and display the following: gross total invoice; time conditional 
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1 discount; other discount / charge; a general adjustments link displays the general 

2 adjustment that was entered for this invoice (the system may only present this link if 

3 this invoice has a general adjustment; the system may show each general adjustment 

4 separately; and the system may permit general adjustments to be removed); sales tax; 

5 other tax; and net amount due. 

6 The system may, upon selection of the messages button 612, display a new 

7 browser window 622 allowing the biller system user to enter a new message for the 

- 8 payer associated with the current invoice. The system may permit new messages to 

9 be entered into a textbox and sent by pressing a "save" button. The system may 

=,10 provide a "cancel" button for discarding the current message and returning to the 

mil invoice detail page. The system may provide a discounts button 61 6 for opening a 

-y 12 separate browser window 626 displaying discounts information for the current invoice, 

Jl3 including, e.g., time conditional discount %; time conditional discount amount; time 

4514 conditional discount date; invoice date; and unconditional discount or charge. The 

^ '15 system may provide a shipping Info button 61 5, which may cause the system to 

J:{16 display additional shipping information for this invoice in a separate browser window 

flJl7 625, including, e.g., ship to location, date shipped, carrier, bill of lading number, terms, 

gl8 units, unit code, weight, volume, package dimensions, package contents, and notes. 

-19 The system may provide a notes button 61 7 for opening a separate browser window 

20 627 containing a list of entered notes for this invoice. In the separate browser window, 

21 the system may permit the user to enter new notes into a new note textbox and save 

22 them by clicking an "add note" button. Clicking a "cancel" button may cause the 

23 system to return the user to the invoice detail page, discarding any new notes. The 

24 system may automatically log adjustment notes and biller disputes as notes for the 

25 current invoice. The system may provide an e-mail button 613 for opening a separate 

26 browser window 623 with a new e-mail referencing the selected invoice. The system 

27 may permit the user to enter an e-mail message to selected users about the current 

28 invoice. The system may permit e-mail to be sent to the recipients that are picked from 

29 the recipients list, the contents of which may be based on the e-mail distribution list set 

30 up by the payer system administrator. The system may provide a status button 614 for 

3 1 opening a separate browser window 624 displaying a page containing the status 
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1 history for the selected invoice, including, e.g., date / time, user ID, and user name and 

2 status. The system may further provide adjustment buttons, e.g., general adjustment 

3 618, quantity adjustment 619, price adjustment 620, and allowance 621 , at the invoice 

4 detail 610 section. The system may permit a general adjustment button 618 to be 

5 selected to open a separate browser window 628 containing general adjustment 

6 information for this invoice. This information may be read-only and may include the 

7 following exemplary items of information: adjustment amount, reason code, and notes. 

8 The system may permit a quantity adjustment button 619 to be selected for a specific 

9 invoice line item to open a separate browser window 629 containing quantity 

10 adjustment information for that line item. This information may be read only and may 

3 1 1 include the following exemplary items of information: adjustment quantity, reason 

ff, 12 code, and notes. The system may permit a price adjustment button 620 to be selected 

tf^ 13 for a specific invoice line item to open a separate browser window containing price 

J 14 adjustment information for that line item. This information may be read only and may 

15 include the following exemplary items of information: new price, reason code, and 

0 16 notes. The system may permit an allowance button 621 to be selected for a specific 

m 17 invoice line item to open a separate browser window 631 containing allowance 

^^18 information for that line item. This information may be read only and may include the 

Hl9 following exemplary items of information: allowance amount, reason code, and notes. 

20 

21 The system may make other options available to the biller system user for 

22 selection, e.g. an items button for displaying the invoice details in item view. The 

23 system may, upon selection of such an button, remove the header from the invoice 

24 details and all but the net amount due field of the footer, thereby allowing more screen 

25 space to be used for the presentation of invoices. The system may provide a search 

26 function for performing a search in the current invoice list. The system may permit 

27 only the invoices currently being displayed to be searched. The system may allow the 

28 user to type a string to search for before selecting the "Search" button. The system 

29 may search each invoice may for the specified string. If a match is found, the system 

30 may scroll the invoice record into view and select the text found. Selecting "Search" 

31 again may cause the system to find the next instance of the string. The system may 
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1 permit wildcard searches. The system may provide clickable line numbers in the items 

2 view line, whereby upon clicking a line item's number, the system may expand the line 

3 to show its invoices, and clicking a particular adjustment may cause the system to 

4 bring up a window with details about that specific adjustment. 

5 The system may permit the biller system user to select an option 608 to retrieve 

6 all closed invoices in the system subject to the criteria set in the view options page and 
- 7 may provide the additional option of restoring selected invoices that have been closed 

8 into the current collection. The system may move invoices that have been checked to 

9 the open state when the user selects an "open" button. 

10 The system may permit the biller system user to select an option 632 to export 

J 1 1 files, i.e. to download data directly from the server, bypassing the need to have the 

€1 12 data flow through a transmission to the biller system user. Selecting the export files 

S 13 option 632 may cause the system to direct the user to the invoice export section 633, 

J 14 from which the user may either edit export templates or export files. Upon selection of 

^1 15 edit export templates, the system may allow the biller system user to edit the 

Q 16 templates used in file export. An export templates listbox may show the present export 

Jj 17 templates while a template settings area may contain all the attributes and settings of 

HIS the current selected template. Upon selection of a template from the export templates 

pl9 listbox, the system may populate the fields of the template settings ar^a. In this area, 

20 the system may allow the biller system user to add, modify, or delete file export 

21 templates by using a set of buttons or controls. The set of invoices to be exported 

22 may be based on the invoices that are being viewed at the time export is chosen. The 

23 system may permit the user to set that filter through the filter/sort page. The template 

24 settings area may contain the following exemplary controls (which the system may be 

25 adapted to store as global Information on the database): fields and export order (may 

26 contain a listbox of the available invoice fields and an ordered listbox of fields marked 

27 for export with two buttons for moving fields between listboxes; up and down buttons 

28 may allow the field export order to be changed); and file formats (a listbox that allows 

29 the file format to be selected; If ASCII is chosen a delimiter section may be displayed 

30 and the user may need to select field and record delimiters). The system may provide 

31 a "set default" button for allowing the user to set the current template as the default 
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1 template for the file export page. Upon selecting file export, the system may allow the 

2 biller system user to export invoices based on an export template. In the templates 

3 listbox, the system may show the present export templates while the export range may 

4 allow the user to select the date range criteria for including invoices in the export. In 

5 the templates list, the system may default to the template set as default from the edit 

6 export templates page; if no default template was set, the system may select the first 

7 entry in the listbox. An "export" button may cause the system to perform the file export, 

8 while a "cancel" button may cause the system to abort. The system may be adapted 

9 to export files in such exemplary formats as 810 for invoices, 820 for payments, XML, 

10 delimited files, and fixed-length PayBase™ compatible files. 

11 The system may permit the biller system user to select a reports option 604, 

12 which may cause the system to display subcategories that correspond to the available 

13 reports. Exemplary reports may include: paid invoices 641 , total invoices 642, 

14 adjusted invoices 643, pending invoices 644, closed invoices 645, credit notes 646, 

15 and statistics 647. Other exemplary reports may include cashflow forecasting, aged 

16 outstanding invoice, returned items, modified invoice history, biller profile 

17 maintenance, payment history, and outstanding invoice status. The system may 

18 permit the user to select from among various reporting options and/or filters 648 

19 (which the system may be adapted to store as global information on the database), 

20 and the system may then generate a report 649 for viewing and/or printing. 

21 Biller System Administration Workflow 

22 Figure 7 illustrates an exemplary biller system administration workflow in one 

23 embodiment of the system. From the administration 700 screen, the system may 

24 permit a biller system administrator to select from among functions including, e.g., edit 

25 biller profile 701 , archive/purge 710, edit banks 702, edit users 703, edit event e-mails 

26 704, edit payers 705, adjustments 706, edit export template 733, and password/profile 

27 change 735. 

28 Upon selection by the biller system administrator of the edit biller profile 701 

29 function, the system may redirect the biller system administrator to a biller profile 

30 section 707 for editing the biller's profile information. The system may permit company 

31 data to be entered and/or edited for the following exemplary fields (which the system 



36 



1 may be adapted to store as global information on the database): name, address, city, 

2 state, zip, country, SIC code, TIN, and default template type. From the biller profile 

3 section 707, the system may permit the biller system administrator to select a function 

4 for editing logos and websites, which may cause the system to direct the administrator 

5 to a logo and website editing page 708, wherein the administrator may edit the bilier's 

6 logos and available websites (which the system may be adapted to store as global 

7 information on the database). The system may display a list of billers, and the 

8 selection of a biller from the list may cause the system to populate the company 

9 information area with details about the current biller. For each biller, the system may 
Q 10 permit a list of company logos and websites to be edited. The system may permit new 
JJl 1 logos to be made available to the system with an "add" button for uploading the logo 
W12 file, and the system may likewise permit logos to be removed from the system with a 
^13 "remove" button. The system may display a list of websites via a listbox containing the 
JJ14 sites and a site details edit area. Selecting a website in the list may cause the system 
1^5 to populate the site details section. The system may permit the URL, description, and 
|3l6 type of website to be edited. The system may provide a delete button for removing a 
^J17 site from the list and a save button for saving the current website. The system may 
ai8 provide a new site button for emptying the edit area to allow a new site to be entered 

19 and saved. The system may provide selectable links for accessing the bilier's 

20 enrollment page and biller profile page. The system may permit the administrator to 

21 select a template editing function, which may cause the system to direct the user to a 

22 template editing section 709. In the template editing section, the system may permit 

23 one or more predetermined, customizable and/or selectable template schema (which 

24 the system may be adapted to store as global information on the database) to be 

25 established and/or edited to format the biller detail, and the system may provide a 

26 single biller multiple templates from which to select. 

27 The system may permit the administrator to select an archive/purge 710 

28 function, wherein the system may direct the administrator to an archive/purge section 

29 71 1 . In this section, the system may permit the administrator to select functions for 

30 archiving (which the system may be adapted to store as global information on the 

31 database), including archiving data to a separate table, modifying options controlling 
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1 when archiving is to occur (e.g. if an invoice stays in the "Presented" or "Viewed" state 

2 for more than X days; if an invoice stays in the "Paid" state for more than X days; 

3 and/or when an invoice is closed, it may be automatically archived); and reporting 

4 against archived data. The system may provide purging features (which the system 

5 may be adapted to store as global information on the database), including purging 

6 records only from the archive table(s); modifying options controlling when to purge 

7 (e.g. purge records after X days in archive; or manual purge). 

8 Upon selection by the biller system administrator of the edit banks 702 function, 

9 the system may redirect the biller system administrator to a biller bank editing section 
10 712 for allowing the bank information associated with the biller to be edited. It is 

Q 11 contemplated that a biller may have multiple banks with each bank having multiple 

12 bank accounts. An exemplary edit banks 712 section may be separated into two 

W 13 sections. In the first section, the system may display the following exemplary fields 

vS 14 (which the system may be adapted to store as global information on the database): 

;f .15 name, address, city, state, zip code, country, country#, account # and RTN. The 

I 16 system may utilize a M0D9 or similar algorithm to verify valid routing numbers. In a 

q17 second section, the system may display for the selected bank a "holidays" list-box 

populated with all bank holidays associated with this bank. Selecting an existing bank 

019 holiday from this list box may cause the system to delete the entry. Selecting a delete 

' 20 button may cause the system to delete the selected bank holiday. The system may 

21 provide combo-boxes for month, day and year selection. Selecting an add button may 

22 cause the system to add the selected date to the holiday list-box. If a bank is added 

23 with, or is caused to have no holidays through later modification, the system may 

24 display a warning to the user. 

25 The system may permit the administrator to select a "users" 703 function, 

26 wherein the system may direct the administrator to an edit user section 713. In this 

27 section, the system may permit the administrator to add, modify or delete users 

28 associated with the current biller. At this page, the system may display the name of the 

29 biller at the top to establish the context of the edit. The system may populate a list box 

30 with the selected biller system's user names. As the administrator clicks on each user, 

31 the system may display the user's information in a user information section. The 
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1 system may permit the administrator to add a new user to the current biller by entering 

2 information into the user information section. The system may require that the 

3 combination of last name, middle initial and first name be unique. The system may 

4 permit modify and delete operations to be performed on the currently selected user. 

5 The system may provide a checkbox for temporarily deactivating a user. The system 

6 may maintain contact information (which the system may be adapted to store as global 

7 information on the database), including, e.g., last name, first, middle, phone, fax, e- 

8 mail, e-mail2, user ID, password, confirmation, language and privilege group. The 

9 system may require certain fields for user information, such as last name, first name, 
10 e-mail and phone. The system may provide a reset password button for resetting the 

3 11 selected user's password to the default setting. The system may automatically send 

12 an e-mail to a new user after they have been added, telling the user how to connect 

€113 and logon to the system. As described above with reference to the host user 

Jl 14 modifying privilege information, the system may similarly permit a biller system 

15 administrator to access a permissions section 715 for modifying permission/privilege 

Q 16 information (which the system may be adapted to store as global information on the 

III 17 database). 

2 18 Upon selection by the biller system administrator of the event e-mails 704 

H 19 function, the system may direct the biller system administrator to an event e-mail 

20 section 714. In this section, the system may permit biller system users to be 

21 associated with specific system events, which associations the system may be 

22 adapted to store as global information on the database. Any time one of these specific 

23 events occurs, the system may generate an automatic e-mail and send it to the 

24 selected list of biller system users. For example, exemplary distribution list choices 

25 may include: invoices loaded successfully, invoices loaded unsuccessfully, invoice 

26 adjusted, payment authorized, payment canceled, payment completed, and payment 

27 notification. The system may display on this page a list-box that contains all biller 

28 system users currently in the selected distribution list and a list-box that contains all 

29 biller system users currently not in the selected distribution list. In one embodiment, 

30 the system may provide two buttons to allow users to be added or removed from the 

31 distribution list. The system may permit a default e-mail address to be set up for each 
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1 event, e.g. the biller system administrator. Tlie system may permit the user to remove 

2 this value and/or add to the list. The system may send an automatic e-mail to one or 

3 more biiler system users when a payment is made. The system may send a summary 

4 of the payments made to each biller that has payments in the given payment run. The 

5 system may send to designated biller system users an e-mail with the following 

6 exemplary information: summary of payments made on today's date, payer name; 
- 7 payer number; total number of payments; and total amount of payments. 

8 The system may further direct the biller system administrator, upon selection of 

9 the payers feature 705, to selections for performing tasks including options 716, 

10 adjustments 717, close invoices 718 and e-mail 719. Selecting the options 716 task 

5 1 1 may direct the biller system administrator to a payer options 720 section, where 

. jS 12 options for a specific payer may be entered and/or edited. The system may display, at 

CI 13 the payer options page, a list-box with all the payers related to the biller, with the 

J 14 system pre-selecting the most recently selected payer in this session by default. If no 

jJl5 payer has previously been selected, then the system may not pre-select a payer in the 

a 16 list box. For the selected payer, the system may display the following exemplary payer 

|jl7 options (which the system may be adapted to store as global information on the 

2;jl8 database): hide line items from invoice listing; allow payments; include signature; web 

h19 site selection (which may be displayed using one or more multiple select listboxes); 

20 logo selection; payer ID; payment methods and account section (may cause the 

21 system to associate payment methods with biller account, and may include a set 

22 default button to establish the biller's default method and account); set default payment 

23 method and account; marketing message; legal text; and payer model. The system 

24 may provide a load default button to fill in all fields with the default entries. The system 

25 may provide a save default button to save the current entries as the default settings. 

26 Hitting the save button may cause the system to save the current payer's options, 

27 while hitting the cancel button may cause the system to discard any changes. 

28 Selecting the adjustments task may cause the system to direct the biller system 

29 administrator to an adjustments section 721 , where the system may permit the 

30 administrator to establish adjustments available to a specific payer and establish an e- 

31 mail notification list. The system may provide a checkbox for enabling and disabling 
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1 disputes. If disputes are enabled, the system may make available for selection in a 

2 listbox the adjustments that the biller will allow the payer system users to make. The 

3 system, through the adjustments listbox, may enable the actual selection of 

4 adjustments available to the payer system users. The system may make all 

5 adjustments selected be available as long as the enable disputes checkbox is 

6 checked. The system may also provide a checkbox for e-mailing one or more biller 

7 system users on adjustments. If this option is selected, the system may enable a 

8 mailing list button for sending automatic e-mails. The system may send to designated 

9 biller system users an e-mail for each adjustment made with the following exemplary 
10 information: "the following adjustment was made by payer name on today's date"; 

^11 payer number; invoice number; adjustment type; adjustment amount; and adjustment 

tfl 12 reason. If there is no address set up to receive this e-mail, the system may send an e- 

5 13 mail message by default to the biller system administrator. The system may permit a 

mailing list function 722 may be accessed by the biller system administrator for 

ms modifying mailing list settings (which may be stored as global information on the 

□16 database). The system may provide a close invoice function 718 for directing the biller 

^;il7 system administrator to a close invoice section 723 to establish invoice-closing criteria 

^418 for each payer. The system may only permit invoices with the status of "paid", 

ni9 "presented", or "viewed" to be closed. All other invoice states may indicate payer 

20 workflow is in progress, and the system may not permit invoices having such states to 

21 be closed. At the payer invoice close page 723, the system may display a list-box with 

22 all the payers related to the biller, with the system pre-selecting the most recently 

23 selected payer in this session by default. If no payer has previously been selected, 

24 then the system may not pre-select a payer from the list-box. For the selected payer, 

25 the system may present invoice closing criteria. The system may process criteria 

26 entered during the next nightly sweep. The system may mark as closed invoices that 

27 meet the closing criteria. Selecting the e-mail 719 task may cause the system to direct 

28 the biller system administrator to a payer e-mail 724 section for associating a list of 

29 biller system users with a specific payer (which associations the system may be 

30 adapted to store as global information on the database). At the payer e-mail page 

31 724, the system may display a list-box with all the payers related to the biller. The 
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system may pre-select the most recently selected payer in this session by default. If no 
payer has previously been selected, then the system may not pre-select a payer from 
the list-box. For the selected payer, the system may display a page having a list-box 
that contains all biller system users currently related to the payer and a list-box that 
contains all biller system users cun-ently unrelated to the payer. The system may 
provide two buttons to allow users to be added or removed from the related list. 

If the biller system administrator selects the adjustments 706 feature, the 
system may further direct the biller system administrator to selections for performing 
adjustment tasks including general 725, quantity 726, price 727, and line item 
allowance 728. When a new biller is created on the channel host, the system may 
give it a full set of the default adjustments for each of the four types (general, quantity, 
price, line item allowance). These system may permit these adjustments to be 
modified, added to, or deleted, allowing full customization by the biller. The system 
may provide a feature for restoring adjustments to the initial defaults. Selecting the 
general 725 button may cause the biller system administrator to be directed to a 
general adjustment codes page 729, wherein the system may permit global general 
adjustment codes to be edited. At this page 729, the system may display an 
adjustment list-box and an adjustment information area. The system may permit 
adjustments to be selected from the list-box to be edited or deleted. The system may 
permit new adjustments to be added by selecting an add button. The system may 
make adjustments entered here available to ail of the biller's payers in the system. 
Exemplary associated fields may include: code and description. Selecting the quantity 
726 button may cause the system to direct the biller system administrator to a quantity 
adjustment codes page 730, wherein the system may permit global quantity 
adjustment codes to be edited. At this page 730, the system may display an 
adjustment list-box and an adjustment information area. The system may permit 
adjustments to be selected from the list-box to be edited or deleted. The system may 
permit new adjustments to be added by selecting an add button. The system may 
make adjustments entered here available to all of the biller's payers in the system. 
Exemplary associated fields may include: code, description, threshold amount (which 
may only be active if "user defined" is not selected), and a "user defined" checkbox. 
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1 Selecting the price 727 button may cause the system to direct the blller system 

2 administrator to a price adjustment codes page 731 , wherein the system may permit 

3 global price adjustment codes to be edited. At this page 731 , the system may display 

4 an adjustment list-box and an adjustment information area. The system may permit 

5 adjustments to be selected from the list-box to be edited or deleted. The system may 

6 permit new adjustments to be added by selecting an add button. The system may 

7 make adjustments entered here available to all of the biller's payers in the system. 

8 Exemplary associated fields may include: code, description, threshold amount (which 

9 may only be active if "user defined" is not selected), and a "user defined" checkbox. 
10 Selecting the line item allowance button 728 may cause the system to direct the biller 

P 1 1 system administrator to a line item allowance adjustment codes page 732, wherein the 
- S 12 system may permit global discount adjustment codes to be edited. At this page 732, 

13 the system may display an adjustment list-box and an adjustment information area. 
*| system may permit adjustments to be selected from the list-box to be edited or 

^15 deleted. The system may permit new adjustments to be added by selecting an add 

1^6 button. The system may make adjustments entered here available to all of the biller's 

§17 payers in the system. Exemplary associated fields may include: code, description, 

lJ18 amount (percentage), fixed or scaled, number of days, and a "penalty assessed" 

Ol9 checkbox. 

20 The system may permit selection of an edit export templates 733 function for 

21 allowing the biller system administrator to edit the templates used in file export in an 

22 edit export template section 734. The system may display an export templates listbox 

23 showing the present export templates. In the template settings area, the system may 

24 display all the attributes and settings of the current selected template. Selecting a 

25 template from the export templates listbox may cause the system to populate the fields 

26 of the template settings area. In this area, the system may allow the biller system user 

27 to add, modify, or delete file export templates by using a set of buttons or controls. 

28 The set of invoices to be exported may be based on the invoices that are being viewed 

29 at the time export is chosen. The system may permit the user to set that filter through 

30 the filter/sort page. The template settings area may contain the following exemplary 

3 1 controls (which the system may be adapted to store as global information on the 
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1 database): fields and export order (may contain a listbox of the available invoice fields 

2 and an ordered listbox of fields marked for export with two buttons for moving fields 

3 between listboxes; via up and down buttons, the system may allow the field export 

4 order to be changed); and file formats (a listbox that allows the file format to be 

5 selected; if ASCII is chosen a delimiter section may be displayed and the system may 

6 require the user to select field and record delimiters). The system may provide a "set 

7 default" button for allowing the user to set the current template as the default template 

8 for the file export page. By selecting file export, the system may allow the biller 

9 system user to export invoices based on an export template. In the templates listbox, 
10 the system may show the present export templates, while, in the export range, the 

y 1 1 system may permit selection of the date range criteria for including invoices in the 

y3 12 export. In the templates list, the system may default to the template set as default 

2 13 from the edit export templates page; if no default template was set, the system may 

14 pre-select the first entry in the listbox. The system may provide an "export" button for 

H 15 performing the file export and a "cancel" button for aborting. 

P 16 The system may provide a password/profile change button 735 for directing the 

biller system administrator to a password/profile change section 736 for changing 

H 1 8 password and/or profile information. 
ni9 Payer System Workflow 

20 Figure 8 illustrates an exemplary payer system workflow in one embodiment of 

21 the system. When a user logs in 801 to the system using the user ID of a payer, the 

22 system may display a payer system administration or "welcome" page 802. The 

23 system may display the user's name at the top in the form of a "Welcome 'Username"' 

24 message, for personalization. The system may display at a payer system 

25 administration page key payer statistics and a list of "action items" with current counts, 

26 amounts in local currency and links to the corresponding pages, as well as information 

27 about the basic functionality of the main topics. The system may also display at this 

28 page information provided by the administrative user regarding how to contact the 

29 administrative user. The current counts may include invoices due today, invoices due 

30 tomorrow, invoices that will lose a discount today, invoices that will lose a discount 

31 tomorrow, invoices past due, invoices outstanding with adjustments, total invoices, 
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verified invoices, initiated payments, authorized payments, and pending payments. 
The system may provide a selection to the user for filtering and/or sorting the counts. 
The system may display a biller list, which may include all billers that the payer has a 
relationship with in the system. The system may permit the payer system user to click 
on any biller to get a list of invoices from that biller. The system may permit the payer 
system user to return to this page by clicking on a link that may be present on every 
page during system access. One area of the screen may contain navigation buttons 
grouped into categories, e.g., invoices due today 803, invoices due tomorrow 804, 
invoices that will lose a discount today 805, invoices that will lose a discount tomorrow 
806, invoices past due 807, outstanding invoices with adjustments 808, total invoices 
809, and verified invoices 810, all of which may link to an Invoice list page 821 to 
display the desired invoices. Other navigation buttons may include initiated payments 
81 1 (which may link to the initiate payment page), authorized payments 812 (which 
may link to the authorize payment page), pending payments 813 (which may link to the 
pending payments page), administration 814 (discussed further hereinbelow at "Payer 
System Administration"), invoices/payments 815, reports 816, and biller directory 817. 
The system may expand these categories into subcategories that modify another 
portion of the screen. One area of the navigation frame may contain the user name 
(not the user ID) who is logged on. The system may allow the user to click on this link 
to modify his or her basic profile information. The system may provide other 
functionality, including a "help" button 818 for directing the user to a help section 819 
and a "logout" button 820 for logging the current user out of the system. 

The system may allow the payer system user to select an option to edit the 
active user profile, wherein the system may direct the payer system user may be 
directed to a page displaying the organization name of the payer at the top, to 
establish the context of the current edit. The system may permit information to be 
maintained and edited at this page and may store the information as global 
information on the database, e.g., last name, first, middle, phone, fax, e-mail, e-mail2, 
password and confirmation. The system may require certain fields for user information, 
including last name, first name, e-mail and phone. The system may include this 
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1 information in e-mails which may be sent through the system and may also make this 

2 information available to biller and payer system administrators. 

3 If the payer system user selects invoices due today 803, invoices due tomorrow 

4 804, invoices that will lose a discount today 805, invoices that will lose a discount 

5 tomorrow 806, invoices past due 807, outstanding invoices with adjustments 808, total 

6 invoices 809, or verified invoices 810, the system may direct the payer system user to 

7 an invoice list page 821 for displaying invoices which meet the corresponding chosen 

8 parameters. At the invoice list page 821 , the system may display to the payer system 

9 user invoices based on selected criteria and/or allow the payer system user to specify 

10 general search criteria for listing invoices. Depending on the selection, the system 

1 1 may direct the user to a "view options" page 822 for filtering and sorting. At the view 

12 options page 822, the system may allow the user control over the subset of data that 

13 will be displayed and the order in which the data will be presented. To further facilitate 

14 the presentation of invoices, the system may automatically save settings associated 

15 with a specific report (which may be stored as global information on the database) and 

16 allow them to be used again the next time the user generates the report. Considering 

17 the time it may take to generate certain reports (e.g. lengthy reports), the system may 

18 also provide an option to bring this page up before running a report, to limit the scope 

19 and time. The view options page may consist of three exemplary areas: extract, sort 

20 and options. In the extract area, the system may provide the following exemplary 

21 choices: by date (past due, eligible for discount, due within xxx days); and by status 

22 (paid invoices, adjusted invoices, unpaid invoices, paid through another source); and 

23 by biller (all biller, specific biller); and by attribute range between xxx and yyy (none, 

24 invoice numbers, store / location, purchase orders, purchase request number, invoice 

25 issue dates, dollar amount, bill of lading numbers, receiving location zipcodes, invoice 

26 aging). The system may also provide the ability to search for invoice number, store or 

27 location number, routing number and P.O. number by using wildcards. The system 

28 may provide a sort area to allow returned results to be sorted in ascending or 

29 descending order according to the following exemplary criteria: due date, invoice 

30 number, invoice date, purchase order number, net amount due, store or location 

31 number, and invoice aging. In one embodiment, the system may determine sorting 



46 



criteria and order by a sort order combo box, which may default to ascending, and 
three sort criteria boxes, the first of which may default to due date, while the rest may 
default to no sort criteria (spaces). The system may provide an options area with the 
following exemplary choices: define page size (for displaying invoices in a paging 
method), remember and use previous settings, and show view options page before 
presentation. The system may be adapted to store extract, sort, and options data as 
global information on the database. 

The system may allow a payer system user to select an option 821 to list 
invoices matching specified criteria. The system may display at this screen the 
filter/sort criteria that are in use for this display. The system may display invoices 
using a paging concept (i.e. 1 - 20 of 362). When displaying invoices, the system may 
remove any existing navigation area, so as to optimize the invoice display area. In 
one embodiment, the system may display a page separated into two sections, with the 
header section containing non-scrolling data and/or buttons and the body section that 
scrolls as necessary, depending upon the width of the browser window and the 
number of invoices being displayed. The header section may contain the following 
elements: 

• The user's selection criteria, i.e.. All Invoices - Past due. 

• The display range text in the format of first - last of maximum, i.e., 1-20 of 200. 

• "Next 'n'" may cause the system to navigate the user to the next "n" invoices, 
i.e., "Next 20". If the last "n" invoices are currently being displayed the system 
may disable the "Next" button. 

• "Previous 'n'" may cause the system to navigate the user to the previous "n" 
invoices, i.e., "Previous 20". If the first "n" invoices are currently being displayed 
the system may disable the "Previous" button. 

• "All" may cause the system to change the mode from displaying a page of 
invoices to displaying all invoices and the system may label the button "Page", 
i.e., 1-200 of 200. If the "Page" button is selected, the system may display at 
this page the first "n" invoices, and the system may label the button "All". 

• "Back" may cause the system to return to the previous screen, step, or function. 
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• "Search" may cause the system to perform a search in the current invoice list by 
using the "Find" feature. The system may permit only the invoices currently 
being displayed to be searched. The system may allow the user to type a string 
to search for before selecting the "Search" button. The system may search each 
invoice for the specified string. If a match is found, the system may scroll the 
invoice record into view and select the text found. Selecting "Search" again may 
cause the system to find the next instance of the string. The system may permit 
wildcard searches. 

• "Show Selected" may cause the system to display all invoices that have been 
manually checked. In the last column of the invoice list, the system may allow a 
user to select individual invoices. While the user remains on this page, the 
system may maintain in a list all invoices that are marked as selected. If the 
user switches the context of this view, the system may not remove any 
selection made by the user. Clicking on the "Show Selected" button may cause 
the system to display all the invoices the user has selected. The system may 
change this button may change to either "Page" or "All", depending on the state 
of the selection when this button was pressed. Selecting this button again may 
cause the system to return the invoice list to its previous mode. The system 
may display all Selected invoices, even if they exceed the page limit. 

• "Paid Through Another Source" may be provided by the system as an option for 
the payer system user to mark an invoice as closed by selecting desired 
invoices and clicking on the "Paid through another source" button. Once this 
occurs, the system may, for the invoices in question, update their audit trail to 
reflect that they were paid outside the system, and then change their status to 
"Closed". 

In the body section, the system may display all invoices in table format. The width of 
the table columns may be proportional to the width of the browser window. If the 
browser window is narrowed, the system may decrease column widths appropriately 
and wrap text within each column, as necessary. If an invoice has adjustments, the 
system may highlight that line in color to indicate this fact. The system may link the 
invoice number field to the invoice detail page. The system may link the status field to 
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1 the invoice history page, at which the system may display a full status history for the 

2 selected invoice. By default, the system may display the following exemplary columns: 

3 biller name (and/or logo{s)), invoice number, due date, status, net amount due, 

4 amount to pay, and select. The payer system administrator may optionally elect to 

5 display additional columns (e.g., P.O. number, P.O. requisition number, store number) 

6 by setting them in the payer profile (which may be stored as global information on the 

7 database). 

8 The system may permit the payer system user to select an option 823 to display 

9 the details of a selected invoice, which may cause the system to direct the user to an 

10 invoice detail section 610. The system may use one or more predetermined, 

1 1 customizable and/or selectable template schema to format the payer detail, and the 

12 system may provide a single payer multiple templates from which to select. The 

13 system may present detail using a selected language associated with the selected 

14 payer and/or user (which the system may be adapted to store as global information on 

15 the database). The invoice detail page may contain various sections. One section 

16 may display summary information for the selected invoice, information about the 

17 payer, information about the particular invoice, and/or information about the biller. The 

18 system may provide selectable buttons for obtaining more information about the 

19 current invoice, e.g., items 831 , messages 832, e-mail 833, status 834, shipping info 

20 835, discounts 836, and notes 837. The system may display line items that have been 

21 adjusted in a different color. Upon selection by a user of the items button 831 , the 

22 system may toggle the header view from showing a detailed header description to 

23 allowing the user to perform basic search operations on the details of this invoice. The 

24 items button 831 may cause the system to toggle to header. Clicking on the header 

25 button may cause the system to return to the previous view, thereby providing more 

26 space for viewing details on the current page, as follows. Another section may contain 

27 the line items that make up the invoice. The system may color code highlight line 

28 items that have been adjusted. Each line may have a clickable line number. Clicking a 

29 line item's number may cause the system to expand the line to show its detail. Clicking 

30 a particular adjustment may cause the system to display a window with details about 

31 that specific adjustment. Another section may contain the invoice summary. For both 
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1 the original amount billed and the amount to pay, the system may calculate and 

2 display the following: gross total Invoice; time conditional discount; other discount / 
, 3 charge; a general adjustments link (which may allow the general adjustment for the 
_ 4 current invoice to be entered or edited); sales tax; other tax; and net amount due. 

5 The system may, upon selection of the messages button 832, display a new 

6 browser window 842 displaying any messages defined by the biller system 

- 7 administrator for this payer. Selection of the discounts button 834 may cause the 

8 system to open a separate browser window 846 displaying additional discount 

9 information for the current invoice, including, e.g., time conditional discount %; time 
10 conditional discount amount; time conditional discount date; invoice date; and 

'^g 1 1 unconditional discount or charge. Selection of the shipping info button 835 may cause 

y 12 the system to display additional shipping information for this invoice in a separate 

%13 browser window 845, including, e.g., ship to location, date shipped, carrier, bill of 

2\l4 lading number, terms, units, unit code, weight, volume, package dimensions, package 

^ 15 contents, and notes. In addition to the invoice specific shipping information, the 

|gl6 system may list courier websites specified by the biller system administrator as links to 

J^^17 the websites of the shipping companies, for shipment tracking or other purposes. 

q18 Selection of the notes button 837 may cause the system to open a separate browser 

^19 window 847 containing a list of entered notes for this invoice. In the separate browser 

20 window, the system may allow the user to enter new notes into a new note textbox and 

21 save them by clicking an "add note" button. Clicking a "cancel" button may cause the 

22 system to return the user to the invoice detail page and discard any new notes. 

23 Selection of the e-mail button 833 may cause the system to open a separate browser 

24 window 843 with a new e-mail referencing the selected invoice. The system may allow 

25 the user to enter an e-mail message to selected users about the current invoice. The 

26 system may send e-mail to the recipients that are picked from the recipients list (which 

27 the system may be adapted to store as global information on the database), the 

28 contents of which may be based on the e-mail distribution list set up by the biller 

29 system administrator. Selection of the status button 834 may cause the system to 

30 open a separate browser window 844 displaying a page containing the status history 

31 for the selected invoice, including, e.g., date / time, user ID, and user name and status. 
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1 The system may further provide adjustment buttons, e.g., general adjustment 838, 

2 quantity adjustment 839, price adjustment 840, and allowance 841 , at the invoice 

3 detail 823 section. The system may permit a general adjustment button 838 to be 

4 selected to open a separate browser window 848 containing general adjustment 

5 information for this invoice. This information may be read only and may include the 

6 following exemplary items of information: adjustment amount, reason code, and notes. 

7 The system may permit a quantity adjustment button 839 to be selected for a specific 

8 invoice line item, which may cause the system to open a separate browser window 

9 849 containing quantity adjustment information for that line item. This information may 

10 be read only and may include the following exemplary items of information: adjustment 

11 quantity, reason code, and notes. The system may permit a price adjustment button 

12 840 to be selected for a specific invoice line item, which may cause the system to 

13 open a separate browser window 850 containing price adjustment information for that 

14 line item. This information may include the following exemplary items of information: 

15 new price, reason code, and notes. The system may permit an allowance button 841 

16 to be selected for a specific invoice line item, which may cause the system to open a 

17 separate browser window 851 containing allowance information for that line item. This 

18 information may be read only and may include the following exemplary items of 

19 information: allowance amount, reason code, and notes. 

20 The system may make other options available to the payer system user for 

21 selection, e.g. an items button for displaying the invoice details in item view. The 

22 system may, upon selection of such a button, remove the header from the invoice 

23 details, and all but the net amount due field of the footer, thereby allowing more screen 

24 space to be used for the presentation of invoices. The system may provide a search 

25 function for performing a search in the current invoice list. The system may permit 

26 only the invoices currently being displayed to be searched. The system may allow the 

27 user to type a string to search for before selecting the "Search" button. The system 

28 may search each invoice may for the specified string. If a match is found, the system 

29 may scroll the invoice record into view and select the text found. Selecting "Search" 

30 again may cause the system to find the next instance of the string. The system may 

31 permit wildcard searches. The system may provide clickable line numbers in the items 
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1 view line, whereby upon clicking a line item's number, the system may expand the line 

2 to show its invoices, and clicking a particular adjustment may cause the system to 

3 bring up a window with details about that specific adjustment. 

4 The system may provide other selectable options, including a website button for 

5 opening a separate browser window containing links to biller-specific websites, and a 

6 biller info button for displaying a new browser window containing the biller information 

7 supplied for the current payer. 

8 From the perspective of the payer system user, the system may identify an 



9 invoice as having one of the following exemplary states: presented, viewed (an invoice 

10 may be considered "viewed" when a invoice display query is built with the invoice 

1 1 included; the user does not necessarily need to actually see the invoice to have it 

12 considered viewed), verified (an invoice that is in this state may be rolled back to 

13 viewed given the user has the permission to verify), payment initiated, payment 

14 authorized, payment pending (an invoice in this state may be rolled back to verified 

15 given the user has the permission to authorize payment), paid, and closed. 

16 As illustrated in the payer invoice/payments workflow diagram of Figure 9, if the 

17 payer system user selects invoice/payments 815, the system may direct him or her to 

18 further select from among invoice/payment selections, which may include, e.g., review 

19 invoice 901 , initiate payment 902, approve/verify invoice 903, authorize payment 904, 

20 pending payment 905, payment history 906, and file export 907. 

21 Selecting the review invoices 901 function may cause the system to direct the 

22 user to an invoice list 908, with appropriate links to invoice status 909, detail 823, and 

23 sorting 910 pages. The invoice list 908, status 909, detail 823, and sorting 910 pages 

24 may be functionally identical to those described above with reference to Figure 8, at 

25 ciphers 821-851. 

26 Selecting the approve/verify invoices 903 function may cause the system to 

27 direct the user to an approve/verify page 91 1 containing an invoice list, with 

28 appropriate links to invoice status 923, detail 823, and sorting 913 pages. The invoice 

29 list, status 923, detail 823, and sorting 913 pages may be functionally identical to those 

30 described above with reference to Figure 8, at ciphers 821-851 . Via the invoice list 

31 shown, the system may permit the payer system user to view all invoices in the system 
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1 that have not yet been approved for payment, subject to the criteria set in the view 

2 options page. The system may provide appropriate functionality to approve an 

3 individual invoice, approve a selection of invoices, or approve all invoices in the 

4 current extract. For any invoice in the extracted set, the system may permit the user to 

5 view the corresponding invoice detail page 823 or the invoice status page 923. 

6 Invoices included on this page may indicate one of the following exemplary states: 

7 presented, viewed, or adjusted. The system may provide appropriate functionality to 

8 confirm approval of an individual invoice or group of invoices. The system may permit 

9 further selection of an "approve invoices" or "verify confirm" 914 page to permit the 

10 user to confirm the requested action. 

1 1 Selecting the initiate payment 902 function may cause the system to direct the 

12 user to an initiate payment page 91 5 containing an invoice list, with appropriate links to 

13 invoice status 909, detail 823, and sorting 910 pages. The invoice list, status 909, 

14 detail 823, and sorting 910 pages may be functionally identical to those described 

15 above with reference to Figure 8, at ciphers 821-851 . Via the invoice list shown, the 

16 system may permit the payer system user to view all invoices in the system that have 

17 been approved for payment, subject to the criteria set in the view options page. The 

18 system ma provide appropriate functionality to initiate payment for an individual 

19 invoice, a selection of invoices, or all invoices in the current extract. For any invoice in 

20 the extracted set, the system may also permit the user to view the corresponding 

21 invoice detail page 823 or the invoice status page 909. The system may display an 

22 "amount to pay" column, the amount shown being net of all applied credits and 

23 adjustments. The system may provide appropriate functionality to perform a cancel, 

24 which action may cause the system to roll back the status to viewed, detaching any 

25 applied credits if necessary. The system may permit the user to toggle between the 

26 discount date and the invoice due date. The system may set payment options to the 

27 default value established for the current biller / payer relationship. The system may 

28 page payments to accurately represent how the payment will be submitted. If the 

29 selection contains applied credit notes, the system may render each in a separate 

30 payment. The system may further permit the user to select a payment initiation 
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1 selection page 916 to confirm the requested action, i.e. to confirm payment initiation of 

2 selected invoices in tfie system. 

3 Selecting the authorize payment function 904 may cause the system to direct 

4 the user to an authorization page 917 containing an invoice list, with appropriate links 

5 to invoice status 912, detail 823, and sorting 913 pages. The invoice list, status 912, 

6 detail 823, and sorting 913 pages may be functionally identical to those described 

7 above with reference to Figure 8, at ciphers 821-851 . Via the invoice list shown, the 

8 system may permit the payer system user to view all invoices in the system that have 

9 had payment initiated, subject to the criteria set in the view options page. The system 
10 may permit the user to click on any check number to view details for that payment 

tj 1 1 group. The system may further permit the payer system user to select check boxes 

2 12 next to payments to select those payments, and to click on an "authorize" button to 

W 13 authorize those selected payments. The system may further permit the user to dick 

^ 14 on an "authorize all" button to authorize all payments listed. The payment method may 

sj 15 be the payment option selected for this transaction, and the initiator may be the user 

I J6 name of the user who authorized the payment. The system may permit the authorize 

ffll7 stage to be automatically bypassed if the payment amount Is less than a pre-selected 

ti l 8 threshold amount. The system may further permit the user to select an authorize 

■'"■ii 

C3l9 payment confirmation page 919 to confirm the requested action, i.e. to confirm 

20 payment authorization of selected invoices in the system, 

21 Selecting the pending payments 905 function may cause the system to direct 

22 the user to a pending payment page 918 containing an invoice list, with appropriate 

23 links to invoice status 912, detail 823, and sorting 913 pages. The invoice list, status 

24 912, detail 823, and sorting 913 pages may be functionally identical to those described 

25 above with reference to Figure 8, at ciphers 821-851 . Via the invoice list shown, the 

26 system may permit the payer system user to view all pending payments in the system 

27 subject to the criteria set in the view options page. The system may permit the user to 

28 click on any check number to view details for that payment group. The system may 

29 further permit the payer system user to select check boxes next to payments to select 

30 those payments, and to click on a "cancel" button to cancel the selected payments. 

31 The system may further permit the user to click on "cancel all payments" to cancel all 
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1 payments listed. Canceling a pending payment may cause the system to roll the 

2 transaction back to the "verified" invoice state. The system may further permit the user 

- 3 toselectacancellationconflrmationpage920toconfinTitherequestedaction, i.e. to 
. 4 confirm canceling pending payments for selected invoices in the system. 

5 Selecting the payment history 906 function may cause the system to direct the 

6 user to a payment history page 921 , wherein the user may view all paid invoices in the 

- 7 system, referencing the corresponding check number, subject to the criteria set in the 

8 view options page. The system may provide an invoice history page 922, whereby the 

9 system may display an invoice history line for each invoice that meets the view options 
^ 10 criteria. Selecting an invoice number link may cause the system to display the 

,11 1 1 corresponding invoice detail page (e.g., as shown and described with respect to cipher 

rj 12 823 of Figure 8). The system may provide an invoice status link for displaying a 

m 13 corresponding invoice status page (e.g. as shown and described with respect to cipher 

J 14 844 of Figure 8). 

15 The system may permit the payer system user to select an export files function 

S 16 907, i.e., to download data directly from the server, bypassing the need to have the 

§ 17 data flow through a transmission to the payer system user. Selecting the export files 

18 option 907 may cause the system to direct the user to the invoice export section 923, 

U 19 from which the user may either edit export templates or export files. Upon selection of 

20 edit export templates, the system may allow the payer system user to edit the 

21 templates used in file export. An export templates listbox may shows the present 

22 export templates while a template settings area may contain all the attributes and 

23 settings of the current selected template. Upon selection of a template from the export 

24 templates listbox, the system may populate the fields of the template settings area. In 

25 this area, the system may allow the payer system user to add, modify, or delete file 

26 export templates (which the system may be adapted to store as global information on 

27 the database) by using a set of buttons or controls. The set of invoices to be exported 

28 may be based on the invoices that are being viewed at the time export is chosen. The 

29 system may permit the user to set that filter through the filter/sort page. The template 

30 settings area may contain the following exemplary controls (which the system may be 

31 adapted to store as global information on the database): document type, document 
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1 status, include (headers and/or line items), fields and export order (may contain a 

2 listbox of the available invoice fields and an ordered listbox of fields marked for export 
, 3 with two buttons for moving fields between listboxes; up and down buttons may allow 

_ 4 the field export order to be changed), file formats (a listbox that allows the file format to 

' 5 be selected; if ASCII is chosen, the system may display a delimiter section and 

- 6 require the user to select field and record delimiters; file formats may Include X12 810, 

. 7 "XML 81 0", PayBase^^, and CSV). The system may provide a "set default" button for 

8 allowing the user to set the current template as the default template for the file export 

9 page. Upon selecting file export, the system may allow the payer system user to 

10 export invoices based on an export template. N the templates listbox, the system may 

Q 1 1 show the present export templates while the export range may allow the user to select 

a 12 the date range criteria for including invoices in the export. The system may provide a 

5 13 "today" checkbox, for aiding in setting the to bounding date to the current date. An 

Cj 14 "export" button may cause the system to perform the file export, while a "cancel" 

H 15 button may cause the system to abort. 

f 1 16 It is noted that the system may further permit a payer system user not only to 

ffil7 view adjusted invoices from the invoice detail screen (e.g. Figure 823, as shown in 

SI 18 Figure 8 and described above), but also to make adjustments to an invoice. In this 

2 19 scenario, from a user interface perspective, the system may allow the original amount 

20 to remain, but may change the "amount to pay" to "amount to adjust". At the bottom of 

21 the invoice, the system may add a new line that reflects the unapproved amount to 

22 pay, subject to any required approval. The system may also allow credit and debit 

23 notes to be entered by a payer system user, whereby credit notes may be entered by 

24 a user and/or handled by the system as invoices with a negative dollar amount, and 

25 debit notes entered by a user and/or handled by the system as invoices. Thus, the 

26 system may permit credit requests to be entered in the same manner as adjustments 

27 are entered. If a credit request is issued, the system may send an e-mail to the 

28 distribution list for this event, referencing the invoice in question (i.e. invoice number, 

29 date, paying company, etc.), amount of credit requested, type of adjustment, 

30 adjustment code, and description of need for credit After an invoice load, the system 

31 may execute a process that sets negative dollar invoices to a "verified" status, so that 
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1 they will appear on the "initiate payment" list. The system may not roll back invoices 

2 with a "verified" status and a negative dollar amount to "presented" or "viewed" status. 
. 3 The system may make a report available to certain users listing all outstanding credit 

. 4 notes, including quantity and total dollar amount. 

5 As shown in the workflow diagrams of Figures 8 and 1 0, the system may permit 

6 the payer system user to select a reports option 816, which may cause the system to 
- 7 display subcategories that correspond to the available reports for selection. 

8 Exemplary reports may include: cashflow forecasting 1001, payment history 1 002, 

9 security administrator statistics 1003, payer profile 1004, invoice summary 1005, 

10 discount 1006, returned items 1007, outstanding invoice statistics 1008, and modified 

3 1 1 invoice summary 1 009. The system may permit the user to select from among various 

« 12 reporting options and/or filters 1010 (which the system may be adapted to store as 

q 13 global information on the database), and the system may then generate a report for 

J 14 viewing and/or printing at a report page 1011. 

15 As shown in the workflow diagram of Figure 8, the system may permit a payer 

p 16 system user to select a biller directory option for displaying a screen containing options 

Ij 17 which, when selected, cause the system to direct the user to pages for viewing biller 

N18 websites and/or e-mail addresses 860 and a biller directory 861 (i.e. a list of available 

519 billers in the system). From the biller directory 861 , clicking on a biller's company 

20 name may cause the system to bring the user to a URL set by the biller system 

21 administrator. 

22 Paver Svstem Administration Workflow 

23 Figure 1 1 illustrates an exemplary payer system administration workflow in one 

24 embodiment of the system. From the administration 1 1 00 screen, the system may 

25 permit a payer system administrator to select from among functions including, e.g., 

26 edit payer profile 1101, edit banks 1 1 02, edit users 1 1 03. edit event e-mails 1 104, edit 

27 biller agreement 1 1 05, and password change 1 1 06. 

28 Upon selection by the payer system administrator of the edit payer profile 1101 

29 function, the system may redirect the payer system administrator to a payer profile 

30 section 1 1 07 for editing the payer's profile information. The system may permit 

3 1 company data to be entered and/or edited for the following exemplary fields (which the 
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1 system may be adapted to store as global information on the database): name, 

2 address, city, state, zip, country, SIC code, TIN, organization type, show invoice list 

3 columns, language for local country presentation, and currency for payment. The 

4 system may provide additional functionality for displaying an "instant payment" 

5 interface and a default settlement dates selector. At the instant payment interface, the 

6 system may permit the administrator to edit the company's instant payment terms that 

7 are used for payment of invoices in the system. The system may allow a payer 

8 system administrator to establish a threshold payment amount for instant payment. If 

9 an invoice comes in with a value less than the threshold amount, the system may be 

10 adapted to immediately initiate and authorize the invoice. When the 810 is loaded, if 

11 an invoice is below the threshold amount, the system may immediately create a 

12 payment, place it in the pending queue, and initiate an audit trail. Instant payment 

13 data (which the system may be adapted to store as global information on the 

14 database) may include the following exemplary fields: Instant payment 

15 (enabled/disabled), threshold amount, default account, default method of payment, 

16 and default settlement date (due date or discount date). The default settlement date 

17 may cause the system to provide additional functionality for the payer of having the 

18 settlement date by default be the due date to receive discounts. The system may 

19 provide the user the ability to change that date. 

20 Upon selection by the payer system administrator of the edit banks 1 102 

21 function, the system may redirect the payer system administrator to a payer bank 

22 editing section 1 109 for allowing the bank information associated with the payer to be 

23 edited. It is contemplated that a payer may have multiple banks with each bank 

24 having multiple bank accounts. An exemplary edit banks 1 109 section may be 

25 separated into three sections. In the first section, the system may display a list-box 

26 containing all the banks associated with the current payer. Selecting a bank from this 

27 list may cause the system to set the context for all other sections and fields of the 

28 page. For the selected bank, the system may display in a second section the following 

29 exemplary fields (which the system may be adapted to store as global information on 

30 the database): name, address, city, state, zip code, country, country*, account # and 

31 RTN. The system may use a M0D9 or similar algorithm to verify valid routing 
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1 

1 numbers. The system may provide a delete button, which may cause the system to 

2 display a confirmation message before deleting the selected bank. Selecting a modify 

- 3 button may cause the system to update the existing bank information with the modified 

- 4 data. Selecting an add button may cause the system to add the current bank 

5 Information as a new bank. The system may require that the bank name and account # 

6 be unique. Pressing a "set default" button may cause the system to set the current 

- 7 bank as the default bank for making payments. In a third section, the system may 

8 display for the selected bank a "holidays" list-box populated with all bank holidays 

9 associated with this bank. Selecting an existing bank holiday from this list box, 

10 followed by the selection of a "delete" button, may cause the system to delete the 

1 1 selected bank holiday. The system may provide combo-boxes for month, day and year 
Jl 12 selection. Selecting an add button may cause the system to add the selected date to 

ill 

^ 13 the holiday list-box. If a bank is added with, or is caused to have no holidays through 

J 14 later modification, the system may display a warning to the user. The system may be 

\j 15 adapted to store holiday data as global information on the database, 
g 16 The system may permit a payer system administrator to select a "users" 1 1 03 

U 17 function, wherein the system may direct the administrator to an edit user section 1110. 

In this section, the system may permit the administrator to add, modify or delete users 

p 19 associated with the current payer. At this page, the system may display the name of 

20 the payer at the top to establish the context of the edit. The system may populate a list 

21 box with the selected payer system's user names. As the administrator clicks on each 

22 user, the system may display the user's information in a user information section. The 

23 system may permit the administrator to add a new user to the current payer by 

24 entering information into the user information section. The system may require that 

25 the combination of last name, middle initial and first name be unique. The system may 

26 permit modify and delete operations to be performed on the currently selected user. 

27 The system may provide a checkbox for temporarily deactivating a user. Contact 

28 information (which the system may be adapted to store as global information on the 

29 database) may be maintained, including, e.g., last name, first, middle, phone, fax, e- 

30 mail, e-mail2, user ID, password and confirmation. The system may require certain 

31 fields for user information, such as last name, first name, e-mail and phone. The 
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1 system may provide a reset password button for resetting the selected user's 

2 password to the default setting. The system may automatically send an e-mail to a 

3 new user after they have been added, telling the user that they have 24 hours to log in 

4 and change their password or the account will be disabled (e.g. where the password is 

5 set to the default of user's last name; the system may permit accounts to be re- 

6 enabled by a payer system administrator). The e-mail may also tell the user how to 

7 connect and logon to the system. The system may provide an "assigned billers" 

8 button for accessing the edit assigned billers page 1111, where the administrator may 

9 assign billers to the current user. At this page, the system may display the name of the 

10 payer and user at the top to establish the context of the edit. At this page, the system 

11 may display a list-box that contains all billers currently assigned to the current user 

12 and a list-box that contains all billers currently not assigned to the current user. The 

13 system may provide two buttons to allow billers to be added or removed from the 

14 assigned list. The system may provide a "permissions" button for permitting access to 

15 the permissions page 1112, wherein the system may permit a user's permission scope 

16 to be narrowed to an organizational subset of the assigned biller. At this page, the 

17 system may allow the administrator to modify permissions associated with the current 

18 user. At this page, the system may display the name of the biller and user at the top to 

19 establish the context of the edit. At this page, the system may display a list of 

20 permissions available to the currently selected user. The system may determine the 

21 permissions available by the permissions available to the current administrator. 

22 Permissions (which the system may be adapted to store as global information on the 

23 database) may be inherited. The system may display in a list of permissions the 

24 organizational defined nodes. A single node may be assigned to the user. By default, a 

25 user may have full permissions. The system may permit the desired permission set to 

26 be selected for the user and then saved with a "save" button. The system may provide 

27 a "cancel" button for exiting and discarding ail changes. The system may provide a 

28 number of pre-defined payer privilege profiles to simplify the security model. The 

29 system may permit the administrator user to choose one of these to give a new user a 

30 particular set of permissions. From there, the system may allow permissions for that 
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1 user to be altered. Exemplary pre-defined payer privilege profiles (which may be 

2 stored as global information on the database) may include: 



. 3 • Security Administrator: May have all payer profile and administration 

4 permissions, including the ability to set-up and delete ID'S, bank accounts and 

~ 5 the payer profile itself. The system may not allow this ID to be connected to any 

■ 6 billers or any processing permissions. The system may permit this ID access to 

- 7 the security administration report only. The system may permit this ID only to be 

8 set-up by the system SuperUser. 

9 • Receiving Supervisor: May be provided with a button called "adjust an Invoice". 
10 With this new button, the system may permit a receiving administrator to be 

'yi 1 1 able to review an invoice and make changes. However, the system may restrict 

^ 12 change permissions to quantity adjustments only. The system may link or map 

* 13 this type of ID to an individual biller or group of billers. 

14 • Purchasing Manager: May be provided with the buttons for list all invoices; 
^'15 approve invoices (keeping ail adjustment capabilities intact); pending payments 

gl6 without the cancel payment privilege; invoice history and biller directories. The 

fylV system may permit all these permissions to be filtered by biller if the ID were 

filS assigned to a particular biller or subset of billers. 

^19 • Payables Administrator: May have permissions for initiate payments, with one 

20 new feature, the ability to create a general invoice adjustment only prior to 

21 creating a payment order; pending payments without the cancel payment 

22 privilege and payment history. The system may permit all these buttons to be 

23 filtered by bank account and biller if the ID were assigned to a particular subset 

24 of bank accounts and/or billers. The system may assign this ID the following 

25 reports: return items. 

26 • Payables Manager: May have permissions for authorize payments; pending 

27 payments with cancel payment permissions; payment history; invoice history; 

28 payer profile and biller directories. The system may allow this role to be filtered 

29 using dollar amount and may assign this ID the following reports: return items. 

30 • Controller: May have permissions for list all invoices; pending payments without 

31 cancel payment permissions; payment history; and invoice history. The system 
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may assign this ID the following reports: cashflow forecasting; outstanding 
invoices; discount management; adjusted invoice history and security 
administrator 

• Cash IVIanager: May have permissions for pending payments without cancel 
payment permissions. The system may assign this ID the following reports: 
cashflow forecasting report. 

Payables Systems Administrator: May be responsible for managing the daily 

file export routine for both unpaid invoices and payments. 

Upon selection by the payer system administrator of the event e-mails 1 104 
function, the system may redirect the payer system administrator to an event e-mail 
section 1113. In this section, the system may permit a list of payer system users to be 
associated with specific system events. Any time one of these specific events occurs, 
the system may generate an automatic e-mail and send it to the selected list of payer 
system users. For example, exemplary distribution list choices may include: invoices 
loaded successfully, invoices approved, payment initiated, payment authorized, 
payment canceled, and payment completed. The system may display at the this page 
a list-box that contains all payer system users currently in the selected distribution list 
and a list-box that contains all payer system users currently not in the selected 
distribution list. In one embodiment, the system may provide two buttons to allow users 
to be added or removed from the distribution list. The system may allow a default e- 
mail address to be set up for each event, e.g. the payer system administrator. 

Selecting edit biller agreement 1 105 may cause the system to direct the payer 
system administrator to an edit biller agreement page 1 1 14, from which the payer 
system administrator may access such exemplary pages as biller organization 1115, 
options 1116, and biller e-mail 1117. 

The system may provide a biller organization page 1 1 1 5 to address the 
enterprise organizational model, the goal being to simulate the business structure of 
an enterprise so that the proper people can have access to and see the appropriate 
information. Although business organizations are hierarchical by definition, this 
structure may be too complex for the intended system implementation. Moreover, 
much of what makes up an organizational hierarchy is not passed as an attribute of an 
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1 invoice transaction. Instead, wiiat may be implemented supports the specificity of the 

2 hierarchical organization, while at the same time assuming no structure. For example, 

3 a biller organization might consist of company, department, region, division or store 

4 units. Assuming that these fields are populated within the invoice transactions of the 

5 system, the system may permit permission sets to be defined, each permission set 

6 being for assigning and establishing data access rights to specific users. Each 

7 permission set may contain one or more uniquely defined combinations. Three 

8 exemplary permission sets might be: Set #1 (Store #1 , Store #2, Store #3); Set #2 

9 (Store #4, Store #5, Store #6); and Set #3 (Division #1 , Division #2). At the biller's 

10 organization page, the system may display a list-box containing all the billers related to 

11 the current payer. The system may pre-select by default the most recently selected 

12 biller in this session. If no biller has previously been selected, then the system may not 

13 pre-select any biller from the list-box. For the selected biller, the system may display 

14 the list of defined organizational elements or permission sets. The system may provide 

15 buttons to add, remove and modify an entry, and may further provide an edit control to 

16 allow editing of the name of the entry. The system may display a second list-box 

17 containing the specific data values that make up the organizational element for the 

18 selected biller. A data value may be made up of the field identifier and the field value. 

19 The system may provide a combo-box that allows the user to select the field identifier, 

20 and the system may provide an edit control to allow the user to enter the field value. 

21 The system may provide buttons to add, remove and modify an entry from this list. 

22 The system may be adapted to store biller organization data as global information on 

23 the database. 

24 Selecting the options function may cause the system to allow the payer system 

25 administrator to establish options for a specific biller using a biller options page 1116. 

26 At the biller options page, the system may display a list-box containing all the billers 

27 related to the payer. The system may pre-select by default the most recently selected 

28 biller in this session. If no biller has previously been selected, the system may not pre- 

29 select any biller from the list-box. For the selected biller, the system may display the 

30 biller options. Exemplary biller options may include: payment methods and account. 
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1 Selecting the biller e-mail function may cause the system to allow the payer 

2 system administrator to associate a list of payer system users with a specific biller 

. 3 using a biller e-mail page 1117. At the biller e-mail page, the system may display a 

4 list-box with all the billers related to the payer. The system may pre-select the most 

- 5 recently selected biller in this session by default. If no biller has previously been 

~ 6 selected, the system may not pre-select any biller from the list-box. For the selected 

7 biller, the system may display at this page a list-box that contains all payer system 

8 users currently related to the biller and a list-box that contains all payer system users 

9 currently unrelated to the biller. The system may provide two buttons to allow users to 
10 be added or removed from the related list. The system may be adapted to store the 

^ 11 foregoing associations as global information on the database. 

€1 12 The system may provide a password change button 11 06, for directing the 

25 13 payer system administrator to a password change section 1 1 20 for changing password 

14 information. 
H 15 Alternative Embodiments 

q 16 It will be appreciated by those skilled in the art that although the functional 

17 components of the exemplary embodiments of the system of the present invention 

%|18 described herein may be embodied as one or more distributed computer program 

r: 19 processes, data structures, dictionaries or other stored data on one or more 

20 conventional general purpose computers (e.g. IBM-compatible, Apple Macintosh, 

21 and/or RISC microprocessor-based computers), mainframes, minicomputers, 

22 conventional telecommunications (e.g. modem, DSL, satellite and/or ISDN 

23 communications), memory storage means (e.g. RAM, ROM) and storage devices (e.g. 

24 computer-readable memory, disk array, direct access storage) networked together by 

25 conventional network hardware and software (e.g. LAN/WAN network backbone 

26 systems and/or Internet), other types of computers and network resources may be 

27 used without departing from the present invention. One or more networks discussed 

28 herein may be a local area network, wide area network, internet, intranet, extranet, 

29 proprietary network, virtual private network, a TCP/IP-based network, a wireless 

30 network, an e-mail based network of e-mail transmitters and receivers, a modem- 
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1 based telephonic network, an interactive telepfionic network accessible to users by 

2 telephone, or a combination of one or more of the foregoing. 

- 3 The invention as described herein may be embodied in a computer residing on 
. 4 a network transaction server system, and input/output access to the invention may 

5 comprise appropriate hardware and software (e.g. personal and/or mainframe 

6 computers provisioned with Internet wide area network communications hardware and 

- 7 software (e.g. CQI-based, FTP, Netscape Navigator™ or iVIicrosoft Internet Explorer™ 

8 HTML Internet browser software, and/or direct real-time TCP/IP interfaces accessing 

9 real-time TCP/IP sockets) for permitting human users to send and receive data, or to 
^. 10 allow unattended execution of various operations of the invention, in real-time and/or 
« 11 batch-type transactions. Likewise, the system of the present invention may be a 

ui 12 remote internet-based server accessible through conventional communications 

13 channels (e.g. conventional telecommunications, broadband communications, wireless 

f> 14 communications) using conventional browser software (e.g. Netscape Navigator^'^ or 

^ 15 Microsoft Internet Explorer^^). Thus, the present invention may be appropriately 

j£j 16 adapted to include such communication functionality and internet browsing ability, 

ni 17 Additionally, those skilled in the art will recognize that the various components of the 

Q 18 server system of the present invention may be remote from one another, and may 

19 further comprise appropriate communications hardware/software and/or LAN/WAN 

20 hardware and/or software to accomplish the functionality herein described. 

21 Each of the functional components of the present invention may be embodied 

22 as one or more distributed computer program processes running on one or more 

23 conventional general purpose computers networked together by conventional 

24 networking hardware and software. Each of these functional components may be 

25 embodied by running distributed computer program processes (e.g., generated using 

26 "full-scale" relational database engines such as IBM DB2™, Microsoft SQL Server™, 

27 Sybase SQL Server™, Oracle 7.3 ™, or Oracle 8.0 ™ database managers, and/or a 

28 JDBC interface to link to such databases) on networked computer systems (e.g. 

29 comprising mainframe and/or symmetrically or massively parallel computing systems 

30 such as the IBM SB2 ™ or HP 9000 ™ computer systems) including appropriate mass 

31 storage, networking, and other hardware and software for permitting these functional 
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1 components to achieve the stated function. These computer systems may be 

2 geographically distributed and connected together via appropriate wide- and local-area 

3 network hardware and software. In one embodiment, program data may be made 

4 accessible to the user via standard SQL queries for analysis and reporting purposes. 

5 Primary elements of the invention may be server-based and may reside on 

6 hardware supporting an operating system such as Microsoft Windows NT/2000™ or 

7 UNIX, Clients may include a PC that supports Apple Macintosh ™, Microsoft Windows 

8 95/98/NT/ME/2000 ™, a UNIX Motif workstation platform, or other computer capable of 

9 TCP/IP or other network-based interaction. In one embodiment, no software other 

10 than a web browser may be required on the client platform. 

11 Alternatively, the aforesaid functional components may be embodied by a 

12 plurality of separate computer processes (e.g. generated via dBase™, Xbase™, MS 

13 Access ™ or other "flat file" type database management systems or products) running 

14 on IBM-type, Intel Pentium™ or RISC microprocessor-based personal computers 

15 networked together via conventional networking hardware and software and including 

16 such other additional conventional hardware and software as may be necessary to 

17 permit these functional components to achieve the stated functionalities, in this 

18 alternative configuration, since such personal computers typically may be unable to 

19 run full-scale relational database engines of the types presented above, a non- 
20 relational flat file "table" (not shown) may be included in at least one of the networked 

21 personal computers to represent at least portions of data stored by a system according 

22 to the present invention. These personal computers may run the Unix, Microsoft 

23 Windows NT/2000 ™ or Windows 95/98/ME ™ operating systems. The aforesaid 

24 functional components of a system according to the present invention may also 

25 comprise a combination of the above two configurations (e.g. by computer program 

26 processes running on a combination of personal computers, RISC systems, 

27 mainframes, symmetric or parallel computer systems, and/or other appropriate 

28 hardware and software, networked together via appropriate wide- and local-area 

29 network hardware and software). 

30 A system according to the present invention may also be part of a larger 

31 computerized financial transaction system comprising multi-database or multi- 
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1 computer systems or "warehouses" wherein other data types, processing systems 

2 (e.g. transaction, financial, administrative, statistical, data extracting and auditing, data 
. 3 transmission/reception, and/or accounting support and service systems), and/or 

. 4 storage methodologies may be used in conjunction with those of the present invention 

5 to achieve an overall information management, processing, storage, search, statistical 

6 and retrieval solution for a particular lock box service provider, e-payment warehouser, 
- 7 biller organization, financial institution, payment system, commercial bank, and/or for a 

8 cooperative or network of such systems. 

9 In one embodiment, source code may be written in an object-oriented 

10 programming language using relational databases. Such an embodiment may include 

O 1 1 the use of programming languages such as C++. Other programming languages 

y 12 which may be used in constmcting a system according to the present invention include 

m 13 Java, HTML, Perl, UNIX shell scripting, assembly language, Fortran, Pascal, Visual 

2 1^ ^3sic, and QuickBasic. Those skilled in the art will recognize that the present 

J 15 invention may be implemented in hardware, software, or a combination of hardware 

= 16 and software. 

g 17 The translation or mapping of EDI-type financial data, particularly of the X12, 

m 18 UN/EDIFACT, and NACHA formats, as discussed herein, is provided herein only as an 

p 19 example of transaction data capable of interacting with the invention and should not be 

^" 20 construed so as to limit the use of the invention solely in such a setting. While the 

21 discussion herein presumes the use of the invention with respect to EDI, transactional, 

22 or financial data, it is anticipated that the invention may have utility in other contexts, 

23 as well. 

24 Payment options such as ACH debits, credit or procurement card payments, 

25 and/or paper checks may be provided. For ACH debits, a 24 hour settlement window 

26 may be required, in which case the payment must be sent to the receiving financial 

27 institution 24 hours prior to the settlement date specified by the payer system user. If 

28 an ACH debit fails, an ACH return file may be sent from the financial institution, in 

29 which case the file is loaded and each transaction may be matched against invoices 

30 with the status of paid. When there is a match, the invoice in question may be 

31 reopened and rolled back to the status of "verified". Paper checks may be generated 
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1 internally or by an external software module, wherein an output file in a format capable 

2 of being read by the external module may be generated. Payment by a payer system 

3 user using a credit or procurement card may also be effected, to be processed by 

4 internet or other means. In this scenario, additional security levels may be included, 

5 e.g., for initiating credit card payments (along with a dollar amount limit) and approving 

6 credit card payments, and such appropriate credit card payment processing 

7 functionality as may be appropriate may be included, as well. 

8 It should also be appreciated from the outset that one or more of the functional 

9 components may alternatively be constructed out of custom, dedicated electronic 

10 hardware and/or software, without departing from the present invention. Thus, the 

1 1 present invention is intended to cover all such alternatives, modifications, and 

12 equivalents as may be included within the spirit and broad scope of the invention as 

13 defined only by the hereinafter appended claims. 

14 It should be recognized by those skilled in the art that the present invention may 

15 have utility in contexts other than invoice payment, and that the parties to transactions 

16 handled by the invention may be entities other than payers and billers/payees in a 

17 vendor/vendee context. For example, the invention may be used in bank-to-bank 

18 transactions, bank-to-consumer transactions, consumer-to-consumer transactions, 

19 and any other financial transactional setting. 

20 Exemplary message definitions and corresponding business objects in one 

21 embodiment of the invention are listed in the table below along with a brief description 

22 of the functions performed by each, wherein exemplary business objects include 

23 AccountMgr, Adjustment, Agreement, Audit, ErrorHandler, FileExport, FinlnstMgr, 

24 GetFinTrans, Getlnvoices, GetPayments, HolidayMgr, Invoicelnfo, LoginManager, 

25 MsgManager, and MsgUtils: 



Messaae 


Business 


DescriDtion 






Object 






Add Account 


AccountMgr 


Adds account to a given financial institution. 




DeleteAccount 


AccountMgr 


Delete account(s) from financial institution. 



68 



GetAccountFinlnst 


AccountMgr 


Retrieves financial institution according to account ID. 


UpdateAccount 


AccountMgr 


Update a financial institution's account information. 


Assign BillerAdJustmentCodeList 


Adjustment 


Take in eitlier a list of Adjustment Code Ids or a set of 
AssignBilierAdjustmentCode messages and add the whole list to the 
bilier ID provided 


RemoveBillerAdjustmentCodeList 


Adjustment 


Take in either a list of Bilier Adjustment Code Ids or a set of 
RemoveBillerAdjustmentCode messages and remove the whole list 
from the bilier ID provided 


AssignPayerAdjustmentCodeList 


Adjustment 


Take in either a list of Adjustment Code Ids or a set of 
AssignPayerAdjustmentCode messages and add the whole list to the 
payer ID provided 




Adjustment 


Take in either a list of Payer Adjustment Code Ids or a set of 
RemovePayerAdjustmentCode messages and remove the whole list 
from the payer ID provided 


GetPayerAdjustmentCodeList 


Adjustment 


Return a PayerAdjustmentCodeList of all codes assigned to the payer 
for a given bilier 


oeiAQj usimeniuoaeList 


Adjustment 


Return an AdjustmentCodeList of all codes that are non-biller specific 


MuuMQjusirneniL'OQ© 


Adjustment 


Add a new adjustment code 


DeleieAdjustmentCode 


Adjustment 


Delete an existing adjustment code. Does not check to see if 
assigned anywhere else, does not update biller/payer adjustment code 
tables 


U Dda tp Ad i 1 1 <5 tm pi n tPriH A 


Adjustment 


Update an adjustment code specified by ID 


GetGeneralAdjustmentList 


Adjustment 


Get a GeneralAdjustmentList of all general adjustments for the given 
invoice ID 


AddGeneralAdjustment 


Adjustment 


Add a general adjustment for a given invoice ID, update the 
agreement counters, and mark the invoice as having been adjusted 


UpdateGeneralAdjustment 


Adjustment 


Update a general adjustment for a given invoice ID, update the 
agreement counters, and mark the invoice as having been adjusted 


DeleteGeneralAdjustment 


Adjustment 


Delete a general adjustment for a given invoice ID, update the 
agreement counters, and check If there are still adjustments for this 
invoice, else unmark the invoice as having been adjusted 


GetLineitemAdjustmentList 


Adjustment 


Get a LIneltemAdjustmentList for a given LineltemDetail 


AddLineltemAdjustment 


Adjustment 


Add a new LineltemAdjustment to the given LineltemDetail by the ID 
provided and update the agreement counters and the 
grossAdjustedTotal amount and the adjusted flag on the invoice 


DeleteLinel tern Adjustment 


Adjustment 


Delete a LineltemAdjustment from the given LineltemDetail by the ID 
provided and update the agreement counters and the 
grossAdjustedTotal amount and the adjusted flag on the invoice 


UpdateLineltemAdjustment 


Adjustment 


uifjuditj d uneiiem/\ajusiment Tor tne given LineltemDetail by the ID 
provided and update the agreement counters and the 
grossAdjustedTotal amount and the adjusted flag on the invoice 


AssignPayerAdjustmentCode 


Adjustment 


Assign an AdjustmentCode to the given payer Id while also providing 
the bilier ID 
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RemovePayerAdjustmentCode 


Adjustment 


Remove an adjustment code from a payer using the given 
PayerAdjustmentCode ID 


GetBiiierAdjustmentCodeList 


Adjustment 


Get a BillerAdjustmentCodeList by tlie provided biller ID 


AssignBillerAdjustmentCode 


Adjustment 


Assign / Create an adjustment code for a biller. If an adjustment code 
is provided, it is assumed to be accurate and the relation is set up in 
the BilferAdjustmentCode table. If there is no adjustment code ID 
provided, the info for creating one can be provided for a biller-specific 
adjustment code and it will establish the relation in 
BillerAdjustmentCode and the entry in AdjustmentCode 


RemoveBillerAdjustmentCode 


Adjustment 


Remove an adjustment code from a biller. If it is a biller-specific code, 
also remove it from the AdjustmentCode table 


UpdateBiilerAdjustmentCode 


Adjustment 


Update the values In an existing BillerAdjustmentCode 


DisplayAdjCode 


Adjustment 


Get adjustment codes for any biller or agreement 


AddAarppmpnt 


Agreement 


Add an agreement for a biller and payer !D combo to the system. 
Must have a biller ID, payer ID, customer number, and biller number 




Agreement 


Remove an agreement for a biller and a payer from the system 


UodatpAcirppmpnt 


Agreement 


Update the values in an agreement 


OClr cJyulorUi DlllSr INUlTlDGr 


Agreement 


Get all of the Payers with agreements for this biller number 




Agreement 


Get all of the Payers who do not have agreements with this biller 
number 


vjcLn oyc;i onui OIIICI ILJ 


Agreement 


Get all of the Payers with agreements for this biiler ID 


GetNon Payers ForBillerlD 


Agreement 


Get all of the Payers who do not have agreements with this biller ID 


GetBillersForPayerlD 


Agreement 


Get all of the Biliers with agreements for this payer ID 


GetNonBillersForPayerlD 


Agreement 


Get all of the Biliers who do not have agreements with this payer ID 


DeleteAgreementList 


Agreement 


Remove the agreements for the list of agreement IDs provided 


GetAgreementList 


MyicfcJiricni 


Get agreement list based on any filter 


GetPayerAgreementList 


Agreement 


Returns InvoiceReviewUI Entity with payer and agreement info 


GetBiiierAgreementList 


Agreement 


Returns InvoiceReviewUI Entity with biller and agreement Info 


AddAuditMsgBulk 


Audit 


Takes a list of audit messages and inserts them into the database. 
Note audit messages can be of type: GENERAL, SYSTEM. 
SECURITY. 


AddAuditMsg 


AUuil 


Adds an audit message to the database. Note audit messages can be 
of type: GENERAL, SYSTEM, SECURITY. 


DeleteAuditMsg 


Audit 


Deletes an audit message from the database. 


GetAuditMsgList 


Audit 


Gets a list of audit messages from the database 
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PostErrorMsg 


ErrorHandler 


Post an error message via the Selector. 


PostError 


ErrorHandler 


Posts an error nnessage directly, without a call through the Selector. 
The function uses ADO to access the database, instead of the 
standard engine calls. 


ExportUnapprovedlnvoicesToCSVFile 


FileExport 


Exports a list of unapproved invoices to character delimited file format. 


ExportUnauthorizedPaymentsToCSVFile 


FileExport 


Exports a list of unauthorized payments to a character delimited file 
format. 


ExportUnapprovedlnvoicesToXMLFile 


FileExport 


Exports a list of unapproved invoices to an XML file. 


ExportUnauthorizedPaymentsToXMLFile 


FileExport 


Exports a list of unauthorized payments to an XML file. 


AddFinlnst 


FinlnstMgr 


Adds a financial institution to the system. 


DeleteFinlnst 


FinlnstMgr 


Deletes a financial institution from the system. 


UpdateFinlnst 


FinlnstMgr 


Updates a financial institution. 


GetFinlnstList 


FinlnstMgr 


Retrieves a financial Institution list for a given biller, or payer- 


DispIayAccount 


FinlnstMgr 


Get account lists for any filter 


DisplayBankList 


FinlnstMgr 


Get current bank info 


GetFinTranList 


GetFlnTrans 


Get a FinTranList. Can either provide where and orderby info or a list 
of FinTran Ids 


GetFinTran 


GetFinTrans 


Get a specfic FinTran by ID 


GetFinTranReviewList 


GetFinTrans 


A light Ul based method for getting FinTrans with a single invoice and 
payment 


GetinvoiceList 


Getlnvoices 


Get an Invoice List. Can either provide where and orderby info or a list 
of Invoice Ids 


Getl nvoicesForPaytnent 


Getlnvoices 


Get an InvoiceReviewUIList for a given paymentid 


GetlnvoiceHistory 


Getlnvoices 


Get a FinTranList for payments which were batched more than 60 
days ago, then display the invoices for them 


Getl nvoiceReviewList 


Getlnvoices 


Get a InvoiceReviewUIList. Can either provide where and orderby info 
or a list of Invoice Ids 


Getl n voice 


Getlnvoices 


Get a specific Invoice by ID 


GetPaymentReviewList 


GetPayments 


Get a PaymentReviewUiList. Can either provide where and orderby 
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info or a list of Payment Ids 


GstPavmf^ntl i<;f 

Ciy 1 1 Id 1 LL.IO L 


GetPayments 


Get a FInTranList. Can either provide where and orderby info or a Iisr~ 
of Payment IDs. Used FInTranList so Xpath filter could work against 
any criteria under it 


GetPaymentHistory 


GetPayments 


Get a FInTranList for payments which were batched more than 60 
days ago, then display the payments for them 


AddHoliday 


nuiiudyiviyf 


Adds a holiday to a specified financial institution. 


UpdateHoliday 


riuiiudyiviyr 


Updates a holiday entry in the database with new information. 


DeleleHoliday 


nuiiudyivigr 


Removes a holiday from a financial institution. 


GetHoiidayList 


HoiidayMgr 


Gets a list of holidays for a given financial institution. 


ValidateSettieinentDate2 


HolidayMgr 


This function can be called directly from any component without the 
Selector. It takes a date, and a financial institution ID. If the date is a 
holiday or a weekend then the next possible workday is returned. 
Otherwise the original date is retumed in string form. 


ValidateSettlementDate 


HoiidayMgr 


If the date is a holiday or a weekend then the next possible workday is 
returned. OthenA^ise the original date Is returned in the XML message 
parameter. 


GetlnvoiceCountsForUser 


Invoice Info 


Get invoice counts for the following: 

Invoices due today, Invoices due tomorrow, Invoices that lose 
discount today, Invoices that lose discount tomorrow, and Invoices 
that are past due. Uses the stored proc Getlnvoicelnfo and passes 
back the counts and the Xpath to select the data set which is placed in 
the payer front screen hypedinks for the counts 


fnPtinvni^^o^tafMol ic+ 

^^Jdll tVUILrCOLdLUoLlol 


invoicelnfo 


Get the InvoiceStatus change entries for a given Invoice ID 


AddlnvoiceStatus 


Invoice! nfo 


Add a new InvoiceStatus record for an Invoice ID 


Login 


LoginManager 


Logs a user into the system, passing it a user name, and password. 
The user will be authenticated against his/her domain credentials as 
well as the NetTransact database information. 


Logoff 


Login Manager 


User logs off according to his/her session ID. A session ID is needed 
as part of the formal message command. 


DispatchMsg 


MsgManager 


Dispatches a message to the selector. If session information is 
needed, then the parameters in the original message body are filled in. 


GetPayerBilIerAdjustmentCodesWithAssign 
ed 


MsgUtils 


Get a BilIerAdjustmentCodeList for the biller supplied, match the 
PayerAdjustmentCodes for the payer supplied to the 
BillerAdjustmentCodes and set the assigned attribute on the 
BilIerAdjustmentCodeList where there is a match. Gives a single list 
for what biller adjustment codes are available and which have been 
assigned to the payer 
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GetPayerAdjustmentCodesWithAssigned 


MsgUtils 


Get all AdjustmentCodes in an AdjustmentCodeList and match the 
PayerAdjustmentCodes for the payer supplied to the 
AdjustmentCodes and set the assigned attribute on the 
AdjustmentCodeList where there is a match. Gives a single list for 
what adjustment codes are available and which have been assigned 
to the payer 


GetBiiierAdjustmentCodesWithAssigned 




Get all AdjustmentCodes in an AdjustmentCodeList and match the 
BillerAdjustmentCodes for the biller supplied to the AdjustmentCodes 
and set the assigned attribute on the AdjustmentCodeList where there 
is a match. Gives a single list for what adjustment codes are available 
and which have been assigned to the biller 
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